#IfWinActive Regression Topic is solved

Report problems with documented functionality
o6711855
Posts: 1
Joined: 04 Jan 2019, 08:46

#IfWinActive Regression

04 Jan 2019, 08:59

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
Posts: 125
Joined: 12 Aug 2017, 04:27

Re: #IfWinActive Regression

04 Jan 2019, 10:16

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
Posts: 2983
Joined: 11 Jan 2017, 17:59

Re: #IfWinActive Regression

04 Jan 2019, 14:57

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
Posts: 3983
Joined: 17 Jul 2016, 01:02
Contact:

Re: #IfWinActive Regression

06 Jan 2019, 12:17

remapping keys wrote: 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
#ifwin wrote: 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.
Last edited by Helgef on 06 Jan 2019, 16:05, edited 1 time in total.
safetycar
Posts: 125
Joined: 12 Aug 2017, 04:27

Re: #IfWinActive Regression

06 Jan 2019, 15:07

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
Posts: 2983
Joined: 11 Jan 2017, 17:59

Re: #IfWinActive Regression

06 Jan 2019, 16:02

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
Posts: 3983
Joined: 17 Jul 2016, 01:02
Contact:

Re: #IfWinActive Regression

06 Jan 2019, 16:09

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
Posts: 3983
Joined: 17 Jul 2016, 01:02
Contact:

Re: #IfWinActive Regression

07 Jan 2019, 07:06

o6711855 wrote: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,
bug fixes wrote:Fixed some hotkeys not using the hook when eclipsed by a wildcard hotkey, depending on the order of definition.
Cheers.
lexikos
Posts: 6652
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: #IfWinActive Regression  Topic is solved

17 Mar 2019, 01:11

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
User avatar
Blue Kodiak
Posts: 26
Joined: 17 Mar 2019, 00:45

Re: #IfWinActive Regression

17 Mar 2019, 02:25

Yeah, encountered this problem before.

Why not:

Code: Select all

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

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 9 guests