Asymmetric Behaviour for (Appskey & Down) vs. (Appskey & Up)

Get help with using AutoHotkey (v1.1 and older) and its commands and hotkeys
mh0
Posts: 5
Joined: 15 Feb 2017, 19:50

Asymmetric Behaviour for (Appskey & Down) vs. (Appskey & Up)

25 Apr 2018, 18:43

I am trying to replicate the mouse wheel functionality using the keyboard - and I settled on mapping the appskey with Up/Down arrow keys to map to the WheelUp/WheelDown. This works fine without modifiers - and scrolling works as expected.

However, when I try using these hotkeys with "Ctrl" - expecting the zoom functionality to kick-in (with Ctrl-WheelUp zooming in, and Ctrl-WheelDown zooming out), only the zooming out functionality works, and the Appskey & Up hotkey does nothing!

Here is the script:

Code: Select all

Appskey & Up::Click WheelUp ; only works for scrolling, *not* zooming
Appskey & Down::Click WheelDown ; works fine for both scrolling and zooming
I have two questions:
  • * I have tried this on several systems, and all of them zoom out just fine, but refuse to zoom in when I press ctrl - does this happen with other folks as well? Is this an AHK bug?
    * Can anyone recommend a fix?
gregster
Posts: 9023
Joined: 30 Sep 2013, 06:48

Re: Asymmetric Behaviour for (Appskey & Down) vs. (Appskey & Up)

25 Apr 2018, 19:16

I cannot replicate your problem. Your code works for me on Win10 with AHK v 1.1.28.02 (newest version). Although a regular remapping works even better for me in some programs (strictly speaking, you used a hotkey here, not a remapping) - but perhaps too good; in Firefox, for example, it seems to always zoom in/out two steps on one keypress:

Code: Select all

Appskey & Up::WheelUp 
Appskey & Down::WheelDown
Your method seems a bit more unreliable in some programs when I try to zoom, but it still works for me, especially if I only want to zoom in/out one step. Not sure, if SetMouseDelay could improve the situation.

Which versions are you running? You can use this line to find out:

Code: Select all

Msgbox % "v" A_AhkVersion " " (A_PtrSize = 4 ? 32 : 64) "-bit " (A_IsUnicode ? "Unicode" : "ANSI")  " Admin " A_IsAdmin " on " A_OSVersion
In which programs did you try to zoom?
mh0
Posts: 5
Joined: 15 Feb 2017, 19:50

Re: Asymmetric Behaviour for (Appskey & Down) vs. (Appskey & Up)

02 May 2018, 18:57

Thank you so much for your response! To answer your questions:
* I am using AHK 1.1.24.00
* 64 bit Unicode Admin 0 on 10.0.16299
+ I am using AHK from PortableApps.com (there's an update to version 1.1.28.00 Dev Test 1 available there that I haven't upgraded to as I prefer stable branches where possible, but may experiment with if it's working on your version).

The zoom with WheelUp does not work anywhere - whereas the WheelDown works everywhere (Outlook, Browsers (Firefox, Edge), Notepad2, etc.)

BTW - your code does not work for me, I get the following message box:
Line Text: *Appskey & Up::
Error: Invalid hotkey.
I used it instead of my code, but maybe I need to use it some other way - owing to the difference between hotkeys and remappings you were describing. Let me know if you know why it didn't work for me.
gregster
Posts: 9023
Joined: 30 Sep 2013, 06:48

Re: Asymmetric Behaviour for (Appskey & Down) vs. (Appskey & Up)

03 May 2018, 02:18

That error message seems very strange to me. If I copy these two lines into a script and run it, I don't get this "Invalid hotkey" error. It is especially strange, because I exactly use the same key combination like you.

I don't know anything about PortableApps, but AHK 1.1.24 is from May 2016. While it might be "stable" in the context of PortableApps, there have been alot of changes and bugfixes for AHK in the meantime; https://autohotkey.com/docs/AHKL_Change ... v1.1.24.00
I skimmed through the changes and found that in version 1.1.27.00 (https://autohotkey.com/docs/AHKL_Change ... v1.1.27.00) there was a fix affecting AppsKey, while I am not sure in detail what was actually changed there and if it would affect the use of Wheelup in this context.

Did you test in a "fresh" script or did you paste it an existing script that might contain some interfering hotkeys? (But even then, I would rather expect some "duplicate hotkey" error). My guess is that the error message you get is version-related. The problem with your hotkeys probably too. I just tried again yours - they zoom in and out for me on AHK 1.1.28.02
lexikos
Posts: 9592
Joined: 30 Sep 2013, 04:07
Contact:

Re: Asymmetric Behaviour for (Appskey & Down) vs. (Appskey & Up)

05 May 2018, 01:00

I have the same issue. It is a keyboard hardware limitation: if I press Ctrl + AppsKey + Up, the system does not detect Up, but Down works fine.

anykey::WheelUp is not supported.
The following keys are not supported by the built-in remapping method:
•The mouse wheel (WheelUp/Down/Left/Right).
...
The "Invalid hotkey" error is due to the remapping being expanded to two hotkeys, both of which are invalid because * is not supported (nor would it be useful) for custom combinations. Remapping was fixed to support custom combinations in 1.1.27.01 by omitting the asterisk for those.
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:

*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
So anykey::WheelUp literally calls Send {Blind}{WheelUp DownR} (or DownTemp in older versions) when you press anykey and Send {Blind}{WheelUp Up} when you release it. This is shown in ListLines. "Up" and "Down" are ignored for the mouse wheel, hence scrolling double.
gregster
Posts: 9023
Joined: 30 Sep 2013, 06:48

Re: Asymmetric Behaviour for (Appskey & Down) vs. (Appskey & Up)

05 May 2018, 06:51

Thank you, lexikos. Like always a lot of useful information!
mh0
Posts: 5
Joined: 15 Feb 2017, 19:50

Re: Asymmetric Behaviour for (Appskey & Down) vs. (Appskey & Up)

08 May 2018, 19:02

Wow @Lexikos - thanks for that comprehensive answer. Seriously! A couple of closing comments though:
  • As per the documentation you quoted, neither WheelUp nor WheelDown should work - do you know why one of them (WheelDown) does however work?
  • I wonder why it was working for @gregster though? Or did you mean it is a limitation of certain keyboards, but not others.
lexikos
Posts: 9592
Joined: 30 Sep 2013, 04:07
Contact:

Re: Asymmetric Behaviour for (Appskey & Down) vs. (Appskey & Up)

09 May 2018, 03:28

mh0 wrote:As per the documentation you quoted, neither WheelUp nor WheelDown should work
No, the documentation does not say what will happen if you try to use them. It says they are not supported. Neither WheelUp nor WheelDown work as you would expect with remapping, but they both have some effect, and both have the same effect aside from scrolling up vs. down (but this isn't guaranteed by the documentation).
do you know why one of them (WheelDown) does however work?
It does not. WheelUp vs WheelDown is irrelevant. As I said, "if I press Ctrl + AppsKey + Up, the system does not detect Up, but Down works fine." If the system does not detect Up, the hotkey never fires, so the script never sends WheelUp in the first place.

Keyboards cannot possibly detect all possible combinations of random keys. Generally they must support all combinations of the standard modifiers, but not necessarily non-modifier keys such as AppsKey. In my case, if Ctrl and AppsKey are held down, the system can detect Down but cannot detect Up. The two keys have difference placement within the keyboard circuitry.
I wonder why it was working for @gregster though? Or did you mean it is a limitation of certain keyboards, but not others.
I only spoke of my own issue, though I would assume yours has the same cause. I have no reason to think that any two different keyboard models would have the same circuitry design. I assume that the circuitry is physically incapable of detecting certain combinations.

Mine is a Microsoft Sculpt keyboard.
mh0
Posts: 5
Joined: 15 Feb 2017, 19:50

Re: Asymmetric Behaviour for (Appskey & Down) vs. (Appskey & Up)

10 May 2018, 17:48

First of all - thanks again for your informative responses - I definitely appreciate the detail and ideas.

I think there's another issue lurking here though.
https://autohotkey.com/docs/misc/Remap.htm - refers to the mouse wheel (WheelUp/Down/Left/Right) not being supported by the built-in remapping method - however, I think that may be irrelevant. As the actual key combination triggers themselves (Appskey & Up - with Ctrl) are not being picked up regardless of what the destination is.

Here is another example:

Code: Select all

Appskey & Up::msgbox foo
Appskey & Down::msgbox bar
Without further modifiers, both foo and bar work - but if I have Ctrl pressed then only bar works. I'm starting to think this is most likely a keyboard thing/bug, because...
Spoiler
lexikos
Posts: 9592
Joined: 30 Sep 2013, 04:07
Contact:

Re: Asymmetric Behaviour for (Appskey & Down) vs. (Appskey & Up)

11 May 2018, 16:29

I think there's another issue lurking here though.
Another issue? You make it sound like I didn't already point out both issues.
mh0
Posts: 5
Joined: 15 Feb 2017, 19:50

Re: Asymmetric Behaviour for (Appskey & Down) vs. (Appskey & Up)

16 May 2018, 16:42

I re-read your comment - I didn't realize you had already moved to the next topic (Invalid Hotkey) when you quoted this
anykey::WheelUp is not supported.

The following keys are not supported by the built-in remapping method:
•The mouse wheel (WheelUp/Down/Left/Right).
...
Which made me mistakenly think you were implying the WheelUp support was connected to the keyboard combination detection issue.

After reading it again, I realize you were right - you explicitly said:
if I press Ctrl + AppsKey + Up, the system does not detect Up, but Down works fine
I stand corrected!

Thanks again folks for helping demystify this, and lexikos for (patiently) sharing your knowledge!

Return to “Ask for Help (v1)”

Who is online

Users browsing this forum: ArkuS, Ineedhelplz and 218 guests