Hi, Tracy - 

Did this user install your app on their Google Drive? If not, where (drive & folder(s)) did they install it?

Do they use a shortcut in which the "Start in" property is set to somewhere on a Onedrive?

regards.

Hi Tracy,

If your application uses GetFileOpenName() or GetFileSaveName() somewhere throughout the application and users navigate away from the directory your application resides in then this will change the current directory.

Per the Help..."The dialog boxes presented by GetFileOpenName and GetFileSaveName are system dialog boxes. They provide standard system behavior, including control over the current directory. When users change the drive, directory, or folder in the dialog box, they change the current directory or folder. The newly selected directory or folder becomes the default for file operations until they exit the application, unless the optional initdir argument is passed."

A couple of ways around it (if not using the initdir argument) are:

1) In the open event of the application object, call GetCurrentDirectory() and store it in either a global variable or an instance variable of the application object.

2) When using either GetFileOpenName() or GetFileSaveName(), include Index 7 or OFN_NOCHANGEDIR in the aFlag argument to restore the current directory (although sometimes I have had mixed results with this).

HTH...regards,

Mark

Hi Tracey,

Could you get the full pathname to the running application and extract the path from that?  That seems like it might be more reliable than using the GetCurrentDirectory function. I've not tried it, but here is a link to a tutorial that will return the full pathname to the executable: https://community.appeon.com/index.php/articles-blogs/tutorials-articles/2-powerbuilder/155-how-to-get-the-application-path.  Note, it uses a loop to find the last / position, but you could use the LastPos function instead.  It looks like the important bit is to use the GetModuleFileNameW function.

As Mark mentioned, get the currentdirectory at the open event of the application object and store that in a global variable.  Use that variable instead of GetCurrentDirectory function elsewhere.

Hi,

This is what we use and it works great, without using GetCurrentDirectory().

See the attached exported code. Unzip the file and import it into a PBL and use this code to run it:

n_applicationPath lnv // autoinstantiated, no CREATE needed.
string ls_appPath

ls_appPath = lnv.of_getApplicationPath()

Hope it solves your problem.

regards,

MiguelL

BTW: Appeon, it seems crazy that we're still not allowed to attach an *.SRU file without having to zip or rename it.

Hi Tracy,

although your initial question has been answered ( the "current directory" that GetCurrentDirectory gets can change for various reasons) I would suggest you "future-proof" your app by using the %APPDATA% folder. You can get the path like this:

constant string KEYWORD = "Keyword"
constant string APPDATA = "Appdata"
ContextKeyword  lcxk_base
string ls_values[]
string ls_appdata

this.GetContextService(KEYWORD, lcxk_base)
lcxk_base.GetContextKeywords(APPDATA, ls_values)
if upperbound(ls_values) >= 1 then
	ls_appdata= ls_values[1]
else
	//you might resort to some fallback solution here or
	//throw an exception because something obviously went wrong
end if

The AppData-Folder is located within the personal folder of the current Windows user. This means every user has write access to it, which *might* not be the case for the location of the application. This also makes it possible to use the app on a terminal server or network share.

If the shortcut on the desktop (or wherever shortcut exists) has the "Start In" folder different from the application, it may be causing this issue.

Suggestions already given should help you find out where your application was actually run from. Keep in mind, if they installed it someplace under "program files" then, you can't write to any sub folder unless the app is run as administrator.

Thank you all for your brilliant advice!  Yes, a new feature I added includes the GetFileOpenName... so obviously that was resetting the current directory.  I decided to use Miguel's solution.  Thank you for including the code for n_applicationPath Miguel! 

I also want to shout out to Benjamin for his insight... it's definitely something to consider if a customer ever decides to host the application from a network share. Right now, I have several other applications and documents in the app directory.  One is the app.ini file, which can be updated when the app is running... so a network share will present a few different problems that might be solved by using the AppData folder.

Again, many thank to all!

~~~Tracy