Solved SalDlgOpenFile changes the working dir

Report TD 5.x and 6.x bugs and possible workarounds.
fakie

SalDlgOpenFile changes the working dir

Post by fakie » 29 Apr 2013, 14:37

Hi,

After a call to SalDlgOpenFile the current dir changes to the folder where the user picks a file. After that a call to a dotnet dll doesnt work as the wrapper uses SalFileGetCurrentDIrectory to retrieve the application directory. As this has changed the dll cannot be found.

regards, Marco

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 3384
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: SalDlgOpenFile changes the working dir

Post by Dave Rabelink » 29 Apr 2013, 17:11

This is normal behavior. The current directory is dynamic and can change during runtime.

To get the folder from the running application use this, it will never change:

https://wiki.tdcommunity.net/index.ph ... ime_folder
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

fakie

Re: SalDlgOpenFile changes the working dir

Post by fakie » 30 Apr 2013, 13:26

Hi Dave,

if what you said is true, gupta should use that method to load the dlls. If one uses the .net wizard to generate apl files, in the generated class Unify_TD_GAIL_CNETBase in Method __Base_Constructor_Overload2 it uses: Call SalFileGetCurrentDirectory( appDir ). After that it calls: GAIL_LoadCustomAssembly(appDir, m_AssemblyName) ). This method fails if the user has done sth causing the file dialog to open (which would change the current dir where the dotnet dlls couldnt be found).

regards, Marco

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 3384
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: SalDlgOpenFile changes the working dir

Post by Dave Rabelink » 01 May 2013, 09:20

You are right. It seems to me the SalFileGetCurrentDirectory which is part of the generated code is incorrect.

Looking at that code what is meant, loading the dll's from the folder where the running application is located.
As said, the Sal function does not provide this folder in all cases.

@Gupta: please have a look at this, to me this is a defect.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

OeavDev
Austria
Posts: 84
Joined: 15 May 2018, 11:18
Location: Vienna

Re: SalDlgOpenFile changes the working dir

Post by OeavDev » 07 Jul 2016, 15:18

This is definitely a defect and I am wondering, how modern gupta software is able to work with .NET assemblies:

FileDialogs are not very uncommon and .NET dlls neither. In combination it's an absolute desaster because of this 'problem'. :?
Last edited by Anonymous on 10 Nov 2016, 09:12, edited 1 time in total.

OeavDev
Austria
Posts: 84
Joined: 15 May 2018, 11:18
Location: Vienna

Re: SalDlgOpenFile changes the working dir

Post by OeavDev » 11 Jul 2016, 08:48

I would like to see a reply from gupta support, if they regard this as a defect and if it gets fixed in near future.

Hint: Gupta should take the path from strArgArray[0]

Return to “Bug Reports”

Who is online

Users browsing this forum: [Ccbot] and 1 guest