#IfWinActive Regression Topic is solved

[o6711855]

Hello,
since version 1.27.00 #IfWinActive is not working as it should. Take this script for example:

Code: Select all

#IfWinActive user
a::b

#IfWinActive
a::Run, notepad

Before 1.27.00:
If the current window is "user", pressing a leads to b, if not, Notepad is started.

Since 1.27.00:
A push of the a-button always leads to a started Notepad. However, if you do just a remapping like "a::c" instead of the Run-Command it is still working. It appears that this erroneous behavior is triggered by "Run".

[safetycar]

I've checked this (using SetTitleMatchMode, 2), and I've found 2 weird things:
- On direct remappings (a::b against a::c) It always prefers the option with title no matter the order, even if the documentation says "only the most recent #If or #IfWin will be in effect".
- If it's not a direct remapping but you do add a command (Run or Send) in the unpreferred one, it will take precedence. If you put it in both it will be back to previous behavior preferring title, over no title.

[swagfag]

on 1.1.30.1 w64:

Code: Select all

#IfWinActive ahk_exe notepad.exe
a::b

#IfWinActive
a::Run calc.exe

prep:

• open notepad
• focus notepad
• press a
• an outputted b is expected, but instead calculator opens

its the same with #If WinActive(), too

[Helgef]

When a script is launched, each remapping is translated into a pair of hotkeys. For example, a script containing a::b actually contains the following two hotkeys instead:

Code: Select all

*a::
SetKeyDelay -1   ; If the destination key is a mouse button, SetMouseDelay is used instead.
Send {Blind}{b DownR}  ; DownR is like Down except that other Send commands in the script won't assume "b" should stay down during their Send.
return

*a up::
SetKeyDelay -1  ; See note below for why press-duration is not specified with either of these SetKeyDelays.
Send {Blind}{b up}
return

Also, any hotkey with a wildcard prefix (*) is entirely separate from a non-wildcard one; for example, *F1 and F1 would each have their own set of variants.

It seems it works as expected. So you need to do,

Code: Select all

#IfWinActive user
a::b

#IfWinActive
*a::Run, notepad

or

Code: Select all

#IfWinActive user
a::b

#IfWinNotActive user
a::Run, notepad

Cheers.

[safetycar]

I see that as a workaround. The reported above would still be a problem if you had several #IfWinActive conditions and you wanted to code a fallback action for when none are met.

[swagfag]

yeah, idk, i mean the remap expansion explains it, but im not entirely convinced it should be that way, that is *a(the hotkey #If variant) being treated differently to a(the global hotkey). for instance, in the example:

Code: Select all

#IfWinActive ahk_exe notepad.exe
*a::Send b

#IfWinActive
a::Run calc.exe

id expect pressing a in notepad to yield a b, and not open calc instead. i understand why it doesnt(its because theyre treated as being different), but still. maybe it was a design choice who knows

the other question would then be: what changed between pre-1.27 and post-1.27, assuming what op claims is correct

[Helgef]

My first code box had an error, I corrected it. It is natural to consider the wild hotkey last, eg, you want ^a to trigger if you press ^a, and *^a if you press,for example shift + ctrl +a, and you do not want all hotkeys to trigger. I'm AFK, sorry for poor formatting. Cheers

[Helgef]

Before 1.27.00:
If the current window is "user", pressing a leads to b, if not, Notepad is started.

You will find that prior to 1.27.00 this was true for your example,

Code: Select all

#IfWinActive user
a::b

#IfWinActive
a::Run, notepad

but not for

Code: Select all

; (only the order of apperance has been changed)
#IfWinActive
a::Run, notepad

#IfWinActive user
a::b

due to an actual bugfix,

Fixed some hotkeys not using the hook when eclipsed by a wildcard hotkey, depending on the order of definition.

Cheers.

[lexikos]

The current behaviour is correct.

As Helgef has pointed out, a::b consists of two hotkeys: *a and *a up. The test script has a third hotkey: a.

Each hotkey has an activation trigger, while each variant of the hotkey may have conditions for firing. The activation triggers are:

• a: Press 'A' with exactly none of the standard modifiers pressed.
• *a: Press 'A' with any combination of modifiers, or none.

When both hotkeys are implemented with the hook (which allows AutoHotkey to control which hotkey should be activated for each keyboard event), a is given precedence over *a since the opposite would prevent a from ever triggering. Having both hotkeys present can still be useful, because *a will trigger if any of the modifier keys is held in combination with 'A'. For the test script, this means Shift+A will activate the remapping if the "user" window is active, even though A on its own runs Notepad.

For a given hotkey, the global variant is used only if no conditional variant is active. However, the test script has only one variant of each hotkey. That is:

• a: global/unconditional
• *a: #IfWinActive user

So there is another simple solution: add a variant for a to override the global variant but perform the same action as *a.

Code: Select all

#IfWinActive user
a::
a::b
a up::
SetKeyDelay -1
Send {Blind}{b up}
return

#IfWinActive
a::Run, notepad

Since a::b expands to the hotkey *a:: followed by the hotkey *a up::, a:: is actually targeting the same subroutine as *a. That only sends key-down, so it is necessary to duplicate the key-up hotkey. It isn't always necessary to duplicate the remapping in full; for instance, this might be sufficient:

Code: Select all

a::
*a::Send {Blind}{b down}
a up::
*a up::Send {Blind}{b up}

...or sometimes this:

Code: Select all

a::
*a::Send b

[Blue Kodiak]

Yeah, encountered this problem before.

Why not:

Code: Select all

#IfWinActive
a::
  IfWinActive , User
    SendInput b
  Else
    Run , Notepad
  Return