SalDlgOpenFile changes the working dir

[fakie]

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]

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

[fakie]

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]

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.

[OeavDev]

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'.

[OeavDev]

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]