lowlevel_keyboard_event_data.h doesn't seem to swallow keyboard events

Environment

Windows build number: 19041.172
PowerToys version: Master/v0.16.0
PowerToy module for which you are reporting the bug: Interface

Steps to reproduce

I’ve been playing around with the source code for FancyZones a lot recently. When adding keybindings the header file interface/lowlevel_keyboard_event_data.h is used to prevent keyboard events being sent to the OS. I don’t believe this functionality actually works. An example given to block Win+L in the file is:

virtual intptr_t signal_event(const wchar_t* name, intptr_t data) override {
    if (wcscmp(name, ll_keyboard) == 0) {
      auto& event = *(reinterpret_cast<LowlevelKeyboardEvent*>(data));
      // The L key has vkCode of 0x4C
      if (event.wParam ==  WM_KEYDOWN && event.lParam->vkCode == 0x4C) {
        return 1;
      } else {
        return 0;
      }
    } else {
      return 0;
    }
  }

Testing this out by altering the code in FancyZones.cpp like thus:

IFACEMETHODIMP_(bool)
FancyZones::OnKeyDown(PKBDLLHOOKSTRUCT info) noexcept
{
    // Return true to swallow the keyboard event
    bool const shift = GetAsyncKeyState(VK_SHIFT) & 0x8000;
    bool const win = GetAsyncKeyState(VK_LWIN) & 0x8000;
    if (win && !shift)
    {
        if ((info->vkCode == VkKeyScan('l')) || (info->vkCode == VkKeyScan('h'))) // <-- h & l hotkeys like vim
        {
            if (m_settings->GetSettings()->overrideSnapHotkeys)
            {
                Trace::FancyZones::OnKeyDown(info->vkCode, win, ctrl, false /*inMoveSize*/);
                return OnSnapHotkey(info->vkCode);
            }
        }
    }
    if (m_dragEnabled && shift)
    {
        return true;
    }
    return false;
}

OnSnapHotkey has been updated accordingly.

Pressing Win+L locks the computer. The window does move accordingly and placing a breakpoint in the if statement shows that it does get hit. The keyboard event just isn’t being swallowed as it should.

Win+L is notoriously difficult to block, though I have found this affects other keys too, like Win+plus which is also not blocked and opens the magnifier.

Expected behavior

The defined key presses should not be passed to the OS.

Actual behavior

Key presses are being passed to the OS preventing them from being effectively rebound.

[arjunbalgovind]

I don’t have a proper resource about which key combinations can’t be blocked, apart from stack overflow answers and just trial and error. While working on the Keyboard Manager(#6) we have found that Win+L and Ctrl+Alt+Del can’t be suppressed. These are two that we are aware of right now. We will be looking into other shortcuts later, but most of the Win shortcuts that we have been testing with seem to get suppressed with low level hooks.

Shall I close the issue?

@crutkas I’ll defer that to you.

[enricogior]

That code has been working consistently since version 0.11, for existing module it hasn’t caused any problem.