Hotkey Control Partially Works

Report problems with documented functionality
User avatar
BGM
Posts: 370
Joined: 20 Nov 2013, 20:56
GitHub: bgmCoder
Contact:

Hotkey Control Partially Works

24 Jul 2017, 22:06

The Hokey control will receive and process media keys but doesn't display them.
Neither can you set the media key values to the control as it's chosen hotkey using guicontrol.

Here is proof.
If you press a media key, such as browser_forward another one, Hokey Control will receive it - and you can even assign the dynamic hotkey, but it leaves the control blank.
Expectation is that the key value shows in the control else it returns blank for keys it cannot work with.

If an improvement is made to this control, perhaps there could be an option to return it's key name instead.
Right now we can use getkeyname() to turn sc135int numpaddivbut it would be nicer to have it done automatically and for the control to recognize this as the hotkey instead of using sc135

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

lexikos
Posts: 5417
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Hotkey Control Partially Works

26 Jul 2017, 04:15

BGM wrote:The Hokey control will receive and process media keys but doesn't display them.

The hotkey control is a standard Windows component, and its limitations are shared by all applications which use it. This is not an AutoHotkey bug.
The Hotkey control has limited capabilities. For example, it does not support mouse/joystick hotkeys or the Windows key (LWin and RWin).

The standard control is responsible for capturing keystrokes and displaying the key text. The text it displays cannot be retrieved or altered other than by assigning a keycode to the control.

AutoHotkey is responsible for converting the keycode to more usable value. This is why GuiControlGet returns values in the standard AutoHotkey format, even though the key names differ from what is displayed (e.g. "Num /" vs NumpadDiv).

I believe the hotkey control's display text directly corresponds to what GetKeyNameText returns. It does not support the multimedia keys.

If an improvement is made to this control, perhaps there could be an option to return it's key name instead.
Right now we can use getkeyname() to turn sc135int numpaddivbut it would be nicer to have it done automatically and for the control to recognize this as the hotkey instead of using sc135

This (above) appears to be written as a separate wish tagged onto the end of your "bug" report, but what you are alluding to is actually a bug. There are comments in the source code indicating it was already "fixed" once before (but the fix is broken):

Code: [Select all] [Download] GeSHi © Codebox Plus

		// Fix for v1.0.37.03: A virtual key that has only one scan code should be resolved by VK
// rather than SC. Otherwise, Numlock will wind up being SC145 and NumpadDiv something similar.
// If a hotkey control could capture AppsKey, PrintScreen, Ctrl-Break (VK_CANCEL), which it can't, this
// would also apply to them.
This will be fixed.
User avatar
BGM
Posts: 370
Joined: 20 Nov 2013, 20:56
GitHub: bgmCoder
Contact:

Re: Hotkey Control Partially Works

26 Jul 2017, 10:27

lexikos wrote:I believe the hotkey control's display text directly corresponds to what GetKeyNameText returns. It does not support the multimedia keys.

The hotkey control returns sc135 but displays Num / the only way to get numpaddivis to use GetKeyNameTexton sc135.
If I push the browser_back button, the hotkey control displays nothing, but returns sc16A.

If the hotkey cannot display a hotkey, then don't you think that it should return blank for those keys? That way it's display corresponds with it's return.

When the Gui Submit command is used, the control's associated output variable (if any) receives the hotkey modifiers and name, which are compatible with the Hotkey command.

What I find is that Gui Submit returns the key names of keys it cannot display, such as media keys.

Right now if I use this control in my app, the user doesn't know that it can't display media keys. So if they push one, the hotkey control still records it and returns the value of the key even though it doesn't display anything. In my code, I can't know that the control doesn't have a useable value because it's variable is not empty.

What I mean is that I think the control ought to return blank for keys it can't display - OR - be made to display the keys it can already capture.
User avatar
jeeswg
Posts: 2694
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Hotkey Control Partially Works

26 Jul 2017, 14:21

It appears that ControlGetText can't retrieve the hotkey control text, but that Acc can. In case that helps at all.

The best solution perhaps would be a custom hotkey control, e.g. using an Edit or Static (what the Gui command calls 'Text') control as the basis.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

lexikos
Posts: 5417
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Hotkey Control Partially Works

26 Jul 2017, 22:27

BGM wrote:The hotkey control returns sc135 but displays Num / the only way to get numpaddiv is to use GetKeyNameText on sc135.
You are talking about GetKeyName. GetKeyName is an AutoHotkey function, which knows about AutoHotkey syntax (like "sc135") and AutoHotkey key names (like "Browser_Back").

GetKeyNameText is not GetKeyName. It is a standard Win32 function.
If the hotkey cannot display a hotkey, then don't you think that it should return blank for those keys?
No, I do not. The control does not display "None"; it displays either nothing or the wrong name.

An observant user will see that the control clearly accepts these keystrokes, even if it doesn't display them. A user can enter a multimedia key and it can work just fine with the script even though it doesn't display the correct name.
User avatar
BGM
Posts: 370
Joined: 20 Nov 2013, 20:56
GitHub: bgmCoder
Contact:

Re: Hotkey Control Partially Works

26 Jul 2017, 23:14

lexikos wrote:An observant user will see that the control clearly accepts these keystrokes, even if it doesn't display them.

That's what I was trying to say the whole time. The control accepts them and displays nothing but it does return sc136 for the key pressed (for browser_back).
I even posted a demo to show that, so I'll take the "observant user" part as a compliment.

lexikos wrote:You are talking about GetKeyName. GetKeyName is an AutoHotkey function, which knows about AutoHotkey syntax (like "sc135") and AutoHotkey key names (like "Browser_Back").

What I meant to say was that the control displays Num / but returns sc135; I only mentioned numpaddivbecause it seemed like a better return value than sc135; and you already addressed that.

The reason I think it should return blank for keys it can't display is because it is confusing for a user. The control cannot show to the user that the key was accepted, and can't display the key if it is pre-loaded. Instead you have to use text controls to explain to the user that the control doesn't work correctly. It would be much better if it could just display the key - but it can't - due to the limitation of the underlying windows control. Since the control is deficient, the way to make it not deficient is to shave off the functionality that it doesn't perform correctly by making it return nothing for keys it can't display.

The other problem I have is that the code cannot tell whether the display is blank. If the user pushes a key that the control cannot display, how can I know? I'd have to make up a list of all the possible keys that the control can't display and compare - just so I could alert the user that key was actually accepted even though the control doesn't indicate it. If the control returned nothing for keys it can't display then there wouldn't be this problem. This is the whole reason I'm posting here at all.
lexikos
Posts: 5417
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Hotkey Control Partially Works

27 Jul 2017, 04:44

Again, the control does not show "None" when you enter a multimedia key. A blank return value would be inconsistent with what the control displays. The control is not necessarily blank either; it shows, for example, "G" when I press Play/Pause and "D" when I press Mute. It is neither logical nor useful for AutoHotkey to return a blank value in those cases.
BGM wrote:The other problem I have is that the code cannot tell whether the display is blank.
Suppose for a second that AutoHotkey is made up of code too, and subject to the same limitations as your script. How then would your wish be implemented?

Some advantages of leaving it to be done in script are:
  • Users who expect the current behaviour won't be surprised and disappointed when their scripts suddenly become unable to capture multimedia keys (and others).
  • Users who want to work around the issue a different way can do so.
  • If the control is ever fixed by Microsoft to display those keys correctly, AutoHotkey will automatically benefit.
  • We're not increasing the code size of AutoHotkey to reduce its capabilities.
  • It will work in current and past versions of AutoHotkey.
User avatar
evilC
Posts: 3574
Joined: 27 Feb 2014, 12:30

Re: Hotkey Control Partially Works

27 Jul 2017, 05:18

If you do not mind using AHK_H, I have written a much more fully-featured hotkey GuiControl which should support any key, and also supports joystick buttons, plus allows you to configure the various modes (Block ~, Wild * etc)
Image
https://autohotkey.com/boards/viewtopic ... 65&t=33070

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 3 guests