Keep same CurrentDir if run from taskbar

[ChrisR]

Is it possible to keep the same current directory if run from the taskbar context menu (tested in v6.10 and previous version)

Code: Select all

; Workaround, around,... uncomment to start a new program instance while keeping the same CurrentDirectory
;SetCurrentDirectory(GetPathPart(ProgramFilename()))
MessageRequester("CurrentDir", "CurrentDirectory: " + GetCurrentDirectory() +#CRLF$+ "vs" +#CRLF$+ "ProgramPath: " + GetPathPart(ProgramFilename()), #PB_MessageRequester_Ok|#PB_MessageRequester_Info)

If CreatePreferences("~Test.pref", #PB_Preference_GroupSeparator)
  PreferenceGroup("General")
  WritePreferenceLong("Run", 1)
  ClosePreferences()
Else
  MessageRequester("Pref not created", "~Test.pref not created in CurrentDirectory (Read only):" +#CRLF$+#CRLF$+ GetCurrentDirectory(), #PB_MessageRequester_Ok|#PB_MessageRequester_Info)
EndIf

If OpenWindow(0, 0, 0, 340, 180, "Run from taskbar context Menu", #PB_Window_SystemMenu|#PB_Window_MinimizeGadget|#PB_Window_MaximizeGadget|#PB_Window_SizeGadget|#PB_Window_ScreenCentered)
  TextGadget(0, 40, 60, 260, 60, "Run a new program instance using the taskbar context menu (right-click)", #PB_Text_Center)
  If OpenPreferences("~Test.pref", #PB_Preference_GroupSeparator)
    ClosePreferences()
  Else
    MessageRequester("Pref not Found", "~Test.pref not Found in CurrentDirectory:" +#CRLF$+#CRLF$+ GetCurrentDirectory(), #PB_MessageRequester_Ok|#PB_MessageRequester_Info)
  EndIf
  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf
DeleteFile(GetCurrentDirectory() + "~Test.pref")

[BarryG]

Just so you know... GetCurrentDirectory() is NOT used to know where your exe is run from. It's used as a WORKING directory, which is why SetCurrentDirectory() can change it. So, no, I wouldn't want this command to be changed from its correct behavior.

[ChrisR]

hmm, my workaround example is confusing.
I don't ask to define the current directory with the directory from which the application loaded.
But to keep the same Current Directory, if it's possible!, when a new instance is started from the taskbar!

When started from explorer, Execute (Win+R), Taskmgr or even Pin to the taskbar, the current directory is the directory from which the application loaded. But not if relaunched from the taskbar context menu (current directory becomes C:\Windows\System32). It can be a concern if you use files, resources with a relative path, thus the SetCurrentDirectory workaround.

Also, if launched from a program in a different access path (ex: RunProgram("..\Test.exe"), the current directory is the path of the calling program but it is not preserved, if relaunched from the taskbar. The bypass above wouldn't work here.

And If SetCurrentDirectory() is used in the program, it will be done in all case of course.
It's not really a concern for me whether it's added or not, I have the workaround for my need but if feasible, I think it would be a bonus, no need to think about it.

[Quin]

+1 for adding this to PB.
I was noticing this in my app, thanks for the workaround, @ChrisR!

[fryquez]

If you use taskbar menu, than explorer.exe will start the new instance.
If it does not have any shortcut info it will end up with C:\Windows\System32 working dir.

Don't see how this is related to Purebasic.

[ChrisR]

I understand about the WorkingDirectory pin shortcut and that it has nothing to do with PB.
SetCurrentDirectory(GetPathPart(ProgramFilename())) or other directory does the job.
But I'm not sure why MS defines the current directory differently if launched from file explorer, Win+R or from taskbar explorer.

[AZJIO]

If you run a program from a CMD file, the directory of the CMD file will become the current directory. If you run it from the AkelPad editor, the current folder will be the AkelPad folder. I encountered this back in AutoIt3. Since I was translating the help, I simply added to the description of the FileChangeDir() function, which is an analogue of SetCurrentDirectory(), text about the benefits of this function as a problem with accessing external files if the program uses relative paths to access files supplied with the program.

I don't think that PureBasic should be a patch for all the shortcomings, since the opposite situation is possible with questions about why the standard behavior for all programs is forced to change by a compiler, which is intended only to compile code, and not to introduce its own preferences for customizing behavior into the code.

You are not limited to forcing the current directory. But this behavior is not obvious to newbies who accidentally encounter the problem.

[Quin]

Honestly the best course of action may be to move this thread/make a new one in tips and tricks. This is useful info, but I now see why adding it to PB wouldn't be wise.

[AZJIO]

I use it like this:

Code: Select all

CurDir$ = GetPathPart(ProgramFilename())
CreatePreferences(CurDir$ + "~Test.pref")

You don’t have to get the path and then trim it, you do it once by storing it in a variable and then use it instead of calling functions.

Code: Select all

Macro CurDir()
  GetPathPart(ProgramFilename())
EndMacro

CurDir$ = CurDir()
Debug CurDir$

[BarryG]

Don't see how this is related to Purebasic.

It's not. GetCurrentDirectory() is a wrapper to the API command GetCurrentDirectory_() on Windows, so it shouldn't be changed.

What ChrisR needs to do to fix his problem, is use AZJIO's solution and not change an existing command, which frankly would break my app and make me switch to using the API version instead.

[ChrisR]

Yes, I realized I got carried away after fryquez's comment, my 2 feet were no longer touching the ground.
It's just good to take this into account when using files or resources with relative paths.
- Using the full path as AZJIO : CreatePreferences(CurDir$ + "~Test.pref")
- Or SetCurrentDirectory(GetPathPart(ProgramFilename())) once at the beginning.

However, I fail to understand why MS defines the current directory with the application path, when calling from File explorer but defines it with %windir%\System32, if launched from taskbar explorer. Without explanation, it looks like a bug to me.

ps: the topic should be moved to Coding Questions

[BarryG]

I fail to understand why MS defines the current directory with the application path, when calling from File explorer but defines it with %windir%\System32, if launched from taskbar explorer.

See here (I think it explains it?) -> https://stackoverflow.com/questions/187 ... -directory

This post in that topic may be relevant -> https://stackoverflow.com/a/18727765/7908170

[HeX0R]

I can't remember having used G/SetCurrentDirectory() in any of my programs!
It might be useful for console programs (which I rarely produce), but in "normal" applications, GetPathPart(ProgramFilename()) should be the way to go.

[BarryG]

Yes, "GetPathPart(ProgramFilename())" is the ONLY way you should get your app's folder. Not GetCurrentDirectory() because that's changable.