LWin hotkey suppresses WM_INPUT message

[Randy31416]

I've got a code that looks at WM_INPUT messages. If I add a hotkey for LWIN, then the WM_INPUT message for the press of LWIN does not get seen. In the code below, the WM_INPUT message for CTRL and for LWIN are seen if I press CTRL and then LWIN together; nothing is seen if I press LWIN by itself; only CTRL is seen if I press LWIN and then CTRL together. If I remove the comment from the ^LWin hot key, then the WM_INPUT is not seen for the CTRL+LWIN combination (pressed in either order). Is the suppression of WM_INPUT intentional? I want to see the WM_INPUT for the LWin itself because then I can detect which of three possible Win keys on my system was pressed. But I also would like to be able to override the Win key.

Code: Select all

    #SingleInstance Force
    #UseHook
    SurfaceTapBegin()
    Return

; ^LWin::OutputDebug, WINDOWS KEY CTRL 
   LWin::OutputDebug, WINDOWS KEY
 
; initialize to trap input messages
  SurfaceTapBegin( )
  {
    AHKHID_Register(1, 6, A_ScriptHwnd, RIDEV_INPUTSINK := 0x00000100)
    OnMessage(WM_INPUT := 0xFF, "SurfaceTapEvent")
  }

; trap wm_input messages and analyze them
  SurfaceTapEvent( wParam, lParam, msg, hwnd )
  {
    Global SurfacePenState
    Critical
    AnyType := AHKHID_GetInputInfo(lParam, II_DEVTYPE := 0)
    AnyHand := AHKHID_GetInputInfo(lParam, II_DEVHANDLE := 8)
    AnyKeys := AHKHID_GetDevInfo(AnyHand, DI_KBD_NUMBEROFKEYSTOTAL := 28, 1)
    AnyCode := AHKHID_GetInputInfo(lParam, II_KBD_VKEY := (14 + A_PtrSize * 2) | 0x0100)
    OutputDebug, KEYS TOTAL [%anykeys%] [%anytype%] [%anycode%]
  }

#Include <hidfuncs>

This script uses the ahkfuncs.ahk include file found at http://www.autohotkey.com/board/topic/3 ... functions/.

[lexikos]

When a keyboard message is suppressed by the keyboard hook, Windows does not generate a WM_INPUT message for it. This is by design of Windows.

[Randy31416]

If I understand you correctly, what you are saying is that AutoHotkey is notified about the keyboard character arrivals before the WM_INPUT message arrives at the OnMessage handler. Then, if AutoHotkey finds a hotkey definition corresponding to the keyboard character, the WM_INPUT message is suppressed (possibly AHK returns that it processed the message). Is this roughly true? I just tried a couple of other hotkey definitions (e.g. "A::OutputDebug, AAA") and the presence of the hotkey definition causes the suppression of the corresponding WM_INPUT message; this makes it seem likely true. If AHK fires a hotkey it suppresses WM_INPUT forwarding, it fires hotkeys before OnMessage, and only surviving WM_INPUT messages get sent to OnMessage. Roughly true?

(For some reason, fortunately, the order of these operations is reversed for pseudo mouse clicks generated by the Surface Pro pen.)

[lexikos]

I meant precisely what I said: Windows does not generate the WM_INPUT message. If the keyboard message (e.g. WM_KEYDOWN) is suppressed by the keyboard hook, WM_INPUT is never sent to the target window, or the script, or any other application. There is no message to be suppressed.

If you use the ~ (pass-through) modifier, the keyboard message is not suppressed. In that case, you would need some other way to prevent the key's native function from activating.

[Randy31416]

OK, but I still don't understand what is happening as accurately as I'd like. Here is what I infer from the immediately above post. AHK sees WM_KEYDOWN, finds a matching hotkey, fires the hotkey, and returns to Windows saying that the WM_KEYDOWN has been processed. If no matching hotkey had been found, then AHK would return to Windows saying that the WM_KEYDOWN had not been processed. So the WM_KEYDOWN is suppressed (i.e. processed because a match was found), Windows is done. I did not know that WM_KEYDOWN (which triggers LWin::) precedes WM_INPUT; becuase of the way the Surface Pen discussion went, WM_INPUT there precedes LButton:: (which is triggered by something esle then).

So I'll look for a solution using this new understanding, and when I've found one or given up I'll post the result.

[Randy31416]

I am giving up on this. After many trials and errors, I reach one of two states.

If I define an LWin key, then I can suppress (redefine) the action of LWin but I cannot determinte the source of the LWin keystroke.

If I do not define an LWin key, then (using WM_INPUT) I can determine the source of the LWin keystroke but I can not suppress the default action of LWin.

[lexikos]

Code: Select all

~LWin:: ; Do not suppress LWin key-down.
    Send {vk07} ; Suppress Start menu.
    ToolTip LWin down
    KeyWait LWin
    ToolTip
    return

Or did you want to suppress Win key combinations as well?

[Randy31416]

Brilliant. Two of the thre LWin keys get trapped by this, and I do get the WM_INPUT that indicates where the keystroke came from. The third key is the Windows key on the bezel of the Surface Pro 3. According to the "key history and script info" view of the running AHK interface, this third key presents an LWin down and then an LWin up with 0.00 delay, and I guess this defeats the KeyWait instruction. In any case, for my work, I'm happy to be able to distinguish the other two and program them (and not have the start screen flash up), and the bezel Windows key (which I almost never use) can serve as an escape. I am only interested in the plain LWin key.

VK_07 is undefined, says Microsoft, and the "key history and script info" lists it as "not found". Does it have a special meaning to AHK, or is its use in your code actually sending LWin+VK07 to Windows and causing it to just ignore both keys?

Lexicos, thanks for the very strong follow-up here (and elsewhere).

[lexikos]

According to the "key history and script info" view of the running AHK interface, this third key presents an LWin down and then an LWin up with 0.00 delay, and I guess this defeats the KeyWait instruction.

That would not prevent the hotkey from firing, but it would prevent you from seeing the tooltip, and it might prevent the Start menu from being suppressed (because LWin up might occur before Send executes).

I used vk07 precisely because it has no meaning. If you press any other key in combination with LWin, the Start menu does not appear.

Lexicos

No.

[Randy31416]

Ouch. I am very sorry. Apologies sent via PM.