2.0-a111 ahk break Topic is solved

[w64bit]

For this simple ahk, a111 is not generating a viable exe.
The error is: Error at line 3. Hostkey or hotstring is missing its opening brace.
I know that there are changes in a111 but I cannot find a way to fix this.
Thank you

Code: Select all

Insert::
#SingleInstance Force
If WinExist ("calc")
    WinActivate "calc"
Else
    Run "C:\Program Files (x86)\calc.exe"
    WinActivate "calc"
Return

[swagfag]

Code: Select all

#SingleInstance Force

Insert::
{
	If WinExist("calc")
	    WinActivate "calc"
	Else
	    Run "C:\Program Files (x86)\calc.exe"
    
    WinActivate "calc"
}

[Helgef]

In the above, the braces serves to define a function body for the hotkey. When the hotkey is triggered, the function is called and passed the name of the hotkey (which excludes the trailing colons), as its first parameter, ThisHotkey.

Every new alpha is also shortly presented in in this thread: AutoHotkey v2 alpha (UPDATES). It is always a good idea to read this before updating.

Cheers.

[Tigerlily]

@Helgef
Wow thanks Helgef, didn't know about this and just been comparing releases on github.

[lexikos]

@w64bit
There are several problems with your code that do not relate to v2.0-a111. Is this your real code?

• The space between WinExist and ("calc") will cause it to be interpreted as WinExist . "calc", where WinExist is an unset variable which will cause a warning. After the warning, the If evaluates to true because "calc" is not an empty string or zero. This means Run is never called.
• As you have not enclosed the two lines after Else in a block, the second WinActivate call is unconditional; i.e. the script will always call WinActivate twice.
• One can usually find a calc.exe in C:\Windows\System32, but usually not C:\Program Files (x86). For files in System32, there's no need to specify the path, so you can just use "calc.exe".
• The standard calculator app is (I think) titled "Calculator", which would be found by "Calc", but not "calc" due to case-sensitivity. WinExist("calc") would just return 0, and WinActivate "calc" would throw an exception.
• Calling WinActivate immediately after Run usually won't work, because the program takes time to launch. It's often necessary to wait for a window belonging to that process to appear. A generally reliable way of doing this is to utilize Run's OutputVarPID parameter.

Code: Select all

Insert::
{
    If !WinExist("ahk_exe calc.exe")
    {
        Run "calc.exe",,, pid
        if !WinWait("ahk_pid " pid,, 3)
            return  ; Not found.
    }
    WinActivate  ; Omit the parameters to use the last found window.
}

Since this is a very common action, it's a good candidate for a reusable function:

Code: Select all

Insert::RunOrActivate "calc.exe"
!Insert::RunOrActivate "notepad.exe"

RunOrActivate(exe) {
    If !WinExist("ahk_exe " exe) {
        Run exe,,, pid
        if !WinWait("ahk_pid " pid,, 3)
            return  ; Not found.
    }
    WinActivate  ; Omit the parameters to use the last found window.
}

@Tigerlily
All changes are noted in the commit log on GitHub...

[w64bit]

v2 128 is giving this warning for your first code:
"This variable appears to never be assigned a value.
Specifically: local pid."
for this line, when compiling exe:

Code: Select all

Run "calc.exe",,, pid

I mention that calc.exe is not Win OS standard calc.

[swagfag]

Code: Select all

#Requires AutoHotkey v2.0-a128-f63b0eb4

Insert::RunOrActivate "calc.exe"
!Insert::RunOrActivate "notepad.exe"

RunOrActivate(exe) {
    If !WinExist("ahk_exe " exe) {
        Run(exe, , , &pid) ; <<<<<<<<< read the ByRef changes
        if !WinWait("ahk_pid " pid, , 3)
            return  ; Not found.
    }
    WinActivate  ; Omit the parameters to use the last found window.
}

[w64bit]

Thank you both very much.