• Options
• Login
• Register
• Desktop Style
• Accelerated Mobile Pages Theme

Application paths support environment variables, but parameter entries do not?

• Index

  • Jean Lalonde Support Forum
  • QUICK ACCESS POPUP FORUM
  • QAP SUPPORT
  • Application paths support environment variables, but parameter entries do not?
• Application paths support environment variables, but parameter entries do not?

• Application paths support environment variables, but parameter entries do not?

  whiggs > 2020-05-15 11:50

  Hello everyone.  So, let me start off by saying I LOVE quick access popup!  I use it literally all the time.  That being said, I did find one issue that, rather than a bug, more like an oversight.  I noticed that, when creating an entry for an application, I can use environment variables for the main application itself, but quick access popup does not correctly extend environment variables for parameters.  I use environment variables throughout quick access popup, since, like I said before, I use the application all the time on many different devices, and, in order to save time, I have my quick access popup config folder backed up to the cloud so that my settings can be quickly imported to other devices.  This makes using direct paths inconvenient, as the direct paths are likely to be different on different devices (using different user accounts).  So, I really liked how quick access popup allowed for the use of environment variables and correctly extended them when configuring the path to the main item to launch.  However, recently, I tried to create a menu item to run an autohotkey script: the main application to launch would be the autohotkey executable and the parameter would be the path to the script file to launch.  So, I configured the quick access popup menu item with these settings:
  
  
  
  
  
  However, when I try to launch this menu item, I get the below error message from the autohotkey executable:
  
  
  
  This tells me that quick access popup is not expanding the environment variables configured for parameters, as substituting the environment variable entry for the full path to the script file in the parameter settings launches the script as expected.  It would be awesome if support for environment variables in parameter settings was added.  Thanks.

• RE: Application paths support environment variables, but parameter entries do not?

  Jean Lalonde > 2020-05-15 13:57

  Hi whiggs,
  
  Thanks for reporting this. Let me check and come back to you.
  
  Jean

• RE: Application paths support environment variables, but parameter entries do not?

  Jean Lalonde > 2020-05-15 16:50

  Hi whiggs,
  
  I verified and the environment variables in the parameter field *are* expanded. The proof is that the error message your 3rd screen capture comes from your script sniploat.ahk (see the title bar). This means that the script has been launched. I could not tell why the %USERPROFILE% is not expanded within SnipFloat.ahk.
  
  But I suggest a different approach to launch AHK scripts from QAP: enter the path to the script in the first tab "Basic Settings" and nothing in the parameters.
  
  Jean

• RE: Application paths support environment variables, but parameter entries do not?

  whiggs > 2020-05-15 17:07

  (2020-05-15 16:50)Jean Lalonde Wrote: Hi whiggs,
  
  I verified and the environment variables in the parameter field *are* expanded. The proof is that the error message your 3rd screen capture comes from your script sniploat.ahk (see the title bar). This means that the script has been launched. I could not tell why the %USERPROFILE% is not expanded within SnipFloat.ahk.
  
  But I suggest a different approach to launch AHK scripts from QAP: enter the path to the script in the first tab "Basic Settings" and nothing in the parameters.
  
  Jean

  
  Thank you for looking into this, but I am afraid that you are not correct in this.  It is the autohotkey executable returning the error, as I just changed the parameter entry for that quick access popup item to a non-existant script in the same folder called cracker.ahk:
  
  
  
  And when running the quick access popup menu with this invalid script name, the non-existent script also shows up in the title bar:
  
  
  

  ---

  (2020-05-15 16:50)Jean Lalonde Wrote: Hi whiggs,
  
  I verified and the environment variables in the parameter field *are* expanded. The proof is that the error message your 3rd screen capture comes from your script sniploat.ahk (see the title bar). This means that the script has been launched. I could not tell why the %USERPROFILE% is not expanded within SnipFloat.ahk.
  
  But I suggest a different approach to launch AHK scripts from QAP: enter the path to the script in the first tab "Basic Settings" and nothing in the parameters.
  
  Jean

  
  Also, I created a couple of test cases to see if I could find a work around/verify the environment variables were expanding.  I created this entry first to test if the environment variables were expanding in the parameters:
  
  
  
  
  
  The result of running entry was that, while it did expand the environment variable, part of the path was cut off, even though it is surrounded in double quotes:
  
  
  
  Indeed, when I tried bypass whatever issue I had stumbled upon by changing the snipfloat entry as seen below:
  
  
  
  
  
  This is the result of running this entry:
  
  

• RE: Application paths support environment variables, but parameter entries do not?

  Jean Lalonde > 2020-05-15 18:01

  I was wrong. QAP does *not* expand the environment variables and does not have to. When launching an app, QAP let Windows expand the variables in the parameters. I could not tell the cause of the error in your scenario involving AutoHotkey.exe but it normally works.
  
  But have you tried this:
  
  > But I suggest a different approach to launch AHK scripts from QAP: enter the path to the script in the first tab "Basic Settings" and nothing in the parameters.
  
  The path would be simply: %USERPROFILE%\OneDrive\always script\snipfloat.ahk (no quotes).

• RE: Application paths support environment variables, but parameter entries do not?

  whiggs > 2020-05-15 20:05

  (2020-05-15 18:01)Jean Lalonde Wrote: I was wrong. QAP does *not* expand the environment variables and does not have to. When launching an app, QAP let Windows expand the variables in the parameters. I could not tell the cause of the error in your scenario involving AutoHotkey.exe but it normally works.
  
  But have you tried this:
  
  > But I suggest a different approach to launch AHK scripts from QAP: enter the path to the script in the first tab "Basic Settings" and nothing in the parameters.
  
  The path would be simply: %USERPROFILE%\OneDrive\always script\snipfloat.ahk (no quotes).

  
  Ok.  Your suggestion worked, but that doesn't really mean the issues I discovered previously aren't still broken, right?

• RE: Application paths support environment variables, but parameter entries do not?

  Jean Lalonde > 2020-05-15 21:23

  Yes, sorry, I did not reply to the second part of your message. From your experience and my own test confirming your findings, we can conclude that QAP does not support "cmd.exe" and /k parameter. But this was never reported before because you do not need it to launch applications or scripts from QAP. You just put the path to the executables (.exe, .bat, .ahk, .vbs, etc.) in the application's path in the first tab and parameters in the advanced settings tab if required.
  
  Thanks for your post. It was interesting investigating this.
• Next Oldest Next Newest