Run shortcut files created by Google Chrome failing. QM Bug?
04-18-2023, 05:59 AM
Now I can reproduce it.
OS resolves shortcuts in a wrong way. If the shortcut is created by a 64-bit app to a file in the 64-bit Program Files folder, when a 32-bit program tries to execute the shortcut, OS changes the target path to the 32-bit Program Files folder, even if the redirected target path does not exist.
Workaround 1: in macro use the shortcut target, not the .lnk file. Drag and drop the shortcut to QM without Ctrl and it inserts run with the shortcut target:
Workaround 2: if want to use .lnk, create another .lnk from a 32-bit app, eg QM, and use it in the macro.
I also tested the same in LibreAutomate, in 64-bit and 32-bit .exe script. If launched from the editor, which is 64-bit, both work. If launched from Explorer, the 32-bit version fails. Maybe it has to do with environment variables like %ProgramFiles%, but it seems changing them in macro with SetEnvVar does not help.
OS resolves shortcuts in a wrong way. If the shortcut is created by a 64-bit app to a file in the 64-bit Program Files folder, when a 32-bit program tries to execute the shortcut, OS changes the target path to the 32-bit Program Files folder, even if the redirected target path does not exist.
Workaround 1: in macro use the shortcut target, not the .lnk file. Drag and drop the shortcut to QM without Ctrl and it inserts run with the shortcut target:
run "C:\Program Files\Google\Chrome\Application\chrome_proxy.exe" " --profile-directory=''Profile 1'' --app-id=nbmjmoobhfdebnjnphkjefkgbhpkkghc" "" "*"Workaround 2: if want to use .lnk, create another .lnk from a 32-bit app, eg QM, and use it in the macro.
CreateShortcut "$desktop$\Chrome-32.lnk" "C:\Program Files\Google\Chrome\Application\chrome_proxy.exe" "--profile-directory=''Profile 1'' --app-id=nbmjmoobhfdebnjnphkjefkgbhpkkghc"I also tested the same in LibreAutomate, in 64-bit and 32-bit .exe script. If launched from the editor, which is 64-bit, both work. If launched from Explorer, the 32-bit version fails. Maybe it has to do with environment variables like %ProgramFiles%, but it seems changing them in macro with SetEnvVar does not help.