4 replies to this topic

[fragman]

I think it would be useful if transparent hotkeys would always be allowed to trigger when their conditions match, even if another hotkey (possibly a capturing one) already fulfilled its conditions and got executed.

This is important in situations where the user may define custom hotkeys but the program wants to use hotkeys in specific situations. It would also help to cut down connections between different program parts which leads to higher modularity.

Is there any technical argument that speaks against this? I realize it might not work for multiple capturing hotkeys (but I'm not sure about that).

Some months ago I brought up a similar issue about capturing and transparent hotkeys excluding each other, even if the condition of the first defined one didn't match. It would also be nice to see this issue resolved.

[Leef_me]

Can you give a definition, and an example, of "transparent hotkeys"

I've heard of "transparent aluminum" in one of the Star Trek movies, but I don't think the two things are related :wink:

[fragman]

I meant hotkeys which pass through to the active application, i.e.

#if WinExist("A")
Enter::
msgbox this is a capturing hotkey
return

;Even though the first hotkey label is used, the others should be allowed to execute as well when their conditions are true.
#if WinActive("A")
~Enter::
DoSomething()
return

#if (true)
~Enter::
DoSomethingDifferent()
return

DoSomething()
{
    msgbox something
}
dosomethingdifferent()
{
    msgbox different
}

I would like if all three hotkey labels would execute when their conditions evaluate to true (which they do here). Since one of them (might be required to restrict it to the first label for performance) is a capturing hotkey that blocks the keys from the active application it should be treated as that. However, the others should still be able to react to the key press.

[Leef_me]

You are tying together two separate mechanisms.

The '~' modifier cannot be turned on/off for a hotkey.
If it is present ~Enter:: then other programs and scripts will not see the {enter}

The '#if' qualifier limits the conditions for allowing the hotkey to fire.
The hotkeys are context sensitive, and in Ahk_basic there must be a different window 'active' or 'existing' to change the context.

I am not familar with how AHK_L treats your 2nd & 3rd hotkeys.
Have you tested just those two together ? If so, do they work ?

[fragman]

I'm fully aware of your comments.

The example I posted will only run the first label.

AHK_L allows much more complex contexts with the #if condition, the one's I used here were just easy nonsense examples.

My point is that:

A) The first matching hotkey (that fulfills its conditions) should determine wether or not ~ is in use.

All other hotkeys that also have fulfilled conditions should also be allowed to execute. This includes those that have or don't have other modifiers but still match the pressed keys.

If there is a problem in backwards compatibility a new modifier could be added that allows this behavior.