Run(Wait) command cannot parse non-exe parameters

[Howard from Toronto]

I'm working on an .ahk script that needs to launch another .ahk script with one or more parameters. For testing, I've made a tiny target script, Testfile.ahk, and also compiled that script as Testfile.exe.

When I try to pass a simple parameter to Testfile, it works for Testfile.exe but not for Testfile.ahk. Here is a test script:

Code: Select all

   RunWait Testfile.exe
   RunWait Testfile.ahk
   RunWait Testfile.exe testing
   RunWait Testfile.ahk testing

The first three commands execute with no problem, and the third one passes the correct parameter, but the last command gives the following error message:

Error: Failed attempt to launch program or document:
Action: <Testfile.ahk testing>
Params: <>

The current thread will exit.

Specifically: The system cannot find the file specified.

Line#
001: RunWait,Testfile.exe
002: RunWait,Testfile.ahk
003: RunWait,Testfile.exe testing
---> 004: RunWait,Testfile.ahk testing
004: Exit

Apparently, the command parser recognizes that what follows ".exe" is a parameter, but it does not recognize that for what follows ".ahk". Instead, it concatenates the parameter into the action, resulting in an invalid action.

[MasterFocus]

This is probably not bug and (I'm guessing here) you're trying to pass a parameter to an AHK file, when you should instead pass any parameters to AutoHotkey.exe along with the script filename. See: http://ahkscript.org/docs/Scripts.htm#cmd

[HotKeyIt]

So it should be:

Code: Select all

RunWait AutoHotkey.exe Testfile.ahk testing

[Howard from Toronto]

I'm not convinced that the original way I did it shouldn't work, since the string "testfile.ahk testing" works properly as a shortcut target (when the path is included), and since the Run/RunWait documentation does not say that only programs, not documents or scripts, may have parameters.

However, I acknowledge that it currently doesn't work, and, that being so, I'd like to thank both MasterFocus and HotKeyIt for providing a workaround that efficiently accomplishes what I need.

[lexikos]

You're both wrong.

It works just fine in AutoHotkey v1.1.14.02, and probably every other version released in the last three years.

[Howard from Toronto]

I was running under version 1.0.48.05, which I downloaded in May 2012, less than two years ago. I assume that, at the time, it was the latest stable version available at http://www.autohotkey.com/download/; I can't see why I wouldn't have downloaded the latest. (I keep a record of the website URLs from which I download software.) The last version of 1.0.x.y was released in April, 2011, and it's not clear from the "Changes & New Features" page when version 1.1 got its first stable release recommended for general use. So, I think it's a bit exaggerated to say "probably every other version released in the last three years". Nonetheless, I appreciate the information that a later version is now the standard one to use.

I've just installed 1.1.14.02, and I can confirm that Run(Wait) does work as I had originally expected. Since someone decided to make the change to the parsing of Run(Wait) commands, I don't think I was incorrect to view the previous behavior as a bug, though some might instead classify it as a bad design decision.

[lexikos]

Between April 2012 and October 2012 the download link pointed at v1.0.48.05, which is the last version released by Chris Mallett. This came about when the current site admin, who has had little or no direct involvement in the development of AutoHotkey, took over and decided he knew what was best for everyone. If you're interested in the history of it, see Formal request to Polyethene.

AutoHotkey_L (now AutoHotkey 1.1) became the main download in October 2010, and again in late October 2012. The Run command was improved to support parameters with any arbitrary file type (including .ahk) in September 2010, so there have been numerous "stable releases" which supported it.

I would not expect you to know all of this, but in any case, it doesn't make sense to report a bug before looking for an update, especially if you haven't updated the program in over a year.