Hi, I'm trying to write an app that gets the current working directory when run from a shortcut. I'm using Lazarus Pascal.
Lets say I have a shortcut in D:\Temp called Test.lnk which runs TestProg.exe (somewhere else, it doesn't matter where).
If I run the app from a shortcut using Windows Explorer then the function GetCurrentDir works perfectly and returns D:/Temp.
But, if I do exactly the same from a DOpus Lister I get "C:\Program Files\GPSoftware\Directory Opus" and NOT the directory of the shortcut, and the windows StartUpInfo flag STARTF_TITLEISLINKNAME is false when it should be true.
Can you help here please, is this by design? If it is how can I get the "Startin" directory or the initial working directory when my app starts?
Are you simply double-clicking the shortcut file in Opus? (Not running it via a toolbar button or anything like that, which has slightly different rules.)
I don't see the same thing here.
If a Start In folder is specified in the shortcut, it is used:
Yes, I'm just double clicking the short cut in both Windows Explorer and in a DOpus Lister, and I get different results.
I looked in the "start in" property and it was %CD% which I believe is an environment variable, and the result is different between Explorer and DOpus, as in the initial post.
However I change the value to blank and now it works the same in both as does it if I hardwired it to a location.
So, thank you, my problem is resolved as I wouldn't normally be using %cd%. However, I'm still a little surprised at the different results when %cd% is used, but then again, I'm not fully ophey with how it gets used as I was testing it after a recommendation.
Is using %CD% in shortcuts documented somewhere, or used by something else? I thought it only worked in Command Prompts, but maybe other things support it as well.
(The difference could just be in which folder Windows ends up falling back on in each program if the Start In path is invalid rather than empty. Or maybe Explorer sets up the variable for things it runs, but I'd never seen it before.)
I'm not sure as I was following a suggestion on another site about getting hold of the 'start in' directory from short cuts. I can't find the post I was looking at, but I've attached another example of 'start in' using an environment variable, so assume that it would also work for %cd%.
%ProgramFiles% is a system-wide env-var so that'd definitely work, but %CD% doesn't usually exist outside of a command prompt, where cmd.exe itself sets it up as a process-local variable each time the CD command is used.
It doesn't seem to exist when File Explorer runs the shortcut. Try making a shortcut which runs this:
"C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /argsmsgbox CD is %CD% ProgramFiles is %ProgramFiles%
Double-click it, even from Explorer, and it will display the same thing:
So we can see %CD% isn't actually defined as anything when File Explorer launches shortcuts.
It could be something that is handled specially for the Start In field, but I don't think it works there either. Create a folder named 1 under the current dir, then try setting the Start In field to %CD%\1 and, no matter which program you double-click the shortcut in, it won't do anything; it still starts in the same folder as if %CD% had been used on its own.
So I think %CD% is simply invalid here, and it's only luck or an implementation quirk that it worked in File Explorer for some reason.
Thanks Leo for taking the time to investigate especially as I'm guessing you've got other things to tackle. As I said, I was trying to solve a problem and came across the use of %cd% in the 'start in' parameter of the short cut, but it didnt actually work for me which is why I found the discrepancy. However I'm thinking you are right in that anything that did appear to work was purely by chance.
But, in doing all this, you have helped me sort my app, so many thanks.
