API — ICoreEssentials/UI/Backends/WinUI/Events

The public contract of 3 header(s) under ICoreEssentials/UI/Backends/WinUI/Events — 2 class/struct definition(s), 0 declaration(s). Each section shows the header's banner and its public (and protected-virtual) surface exactly as the file writes it.

ICoreWinUIEventArgs.h#

ICoreEssentials/UI/Backends/WinUI/Events/ICoreWinUIEventArgs.h

The EXTRACTION half of W1.4's remainder: read the fields off the real XAML event args. Everything that decides anything is in ICoreWinUIEventFields.h; nothing here does more than copy a value out of a WinRT object.

⚠⚠ THIS HEADER NAMES WINRT TYPES AND THEREFORE BELONGS TO THE WINUI BACKEND ZONE AND NOWHERE ELSE. winrt::/Microsoft.UI outside UI/Backends/WinUI/ is exactly what the toolkit-boundary guard forbids, so including this from a widget, a panel or anything above the backend is a rule break, not a style question. (The guard and the row it belongs to are named in the .cpp -- a header's banner is lifted verbatim onto the generated API page, which a reader of the product sees, and this tree's own machinery is not something they can act on.) Include ICoreWinUIEventFields.h there instead -- it is the same translation with the toolkit taken off the front, which is the point of the split.

Declares no class of its own — see the file.

ICoreWinUIEventFields.h#

ICoreEssentials/UI/Backends/WinUI/Events/ICoreWinUIEventFields.h

The DECISIONS half of W1.4's remainder: WinUI's event fields -> the ICore event values a hook receives. The peer of ICoreEventConversion.h's fromMouse()/fromKey()/fromWheel() on the Qt backend.

⚠ NO WINDOWS TYPES AND NO WINRT TYPES IN THIS HEADER, for exactly the reason ICoreWinUIEventMap.h gives: everything below takes plain integers, doubles and bools, so the suite can drive it on a box with no Windows App SDK and no XAML at all. ICoreWinUIEventArgs.h is the other half -- it names PointerRoutedEventArgs and KeyRoutedEventArgs, reads these fields off them, and makes NO decisions of its own. That split is what makes a translation layer testable when its input types can only be constructed by a running XAML tree.

The split is also the answer to the question the landed half of this row

ICoreWinUIPointerFields#

ICoreWinUIEventFields.h:30 · struct · 0 declaration(s)

Everything a PointerRoutedEventArgs carries that an ICoreMouseEvent or an ICoreWheelEvent needs, already extracted.

struct ICoreWinUIPointerFields {
public:
    // GetCurrentPoint(<the receiving element>).Position()
    double localX = 0.0;
    double localY = 0.0;

    // GetCurrentPoint(nullptr).Position() -- the XAML ROOT's coordinates, not
    // the screen's. See screenOriginX/Y.
    double rootX = 0.0;
    double rootY = 0.0;

    // ⚠ THE WINDOW'S TOP-LEFT ON THE SCREEN, AND IT IS A PARAMETER RATHER THAN
    // A LOOKUP ON PURPOSE. QMouseEvent::globalPosition() is in SCREEN
    // coordinates and 55 uses across the scene tier read the value built from
    // it. WinUI's pointer events never carry a screen coordinate: the deepest
    // GetCurrentPoint(nullptr) reaches is the XAML root. The window's position
    // is an AppWindow property, which is W1.2 -- so this struct asks the
    // caller for it instead of guessing, and a seat that has no window yet
    // passes 0 and gets root coordinates, visibly, rather than silently.
    double screenOriginX = 0.0;
    double screenOriginY = 0.0;

    // PointerPointProperties::PointerUpdateKind(), as its integer.
    unsigned int pointerUpdateKind = 0;

    // PointerPointProperties::IsLeft/Right/MiddleButtonPressed().
    bool leftPressed = false;
    bool rightPressed = false;
    bool middlePressed = false;

    // PointerRoutedEventArgs::KeyModifiers(), as its integer.
    // ⚠ Pointer events DO carry the modifier state; key events do not. See
    // ICoreWinUIKeyFields.
    unsigned int keyModifiers = 0;

    // PointerPointProperties::MouseWheelDelta() and ::IsHorizontalMouseWheel().
    int wheelDelta = 0;
    bool horizontalWheel = false;
};
};

ICoreWinUIKeyFields#

ICoreWinUIEventFields.h:74 · struct · 0 declaration(s)

Everything a KeyRoutedEventArgs carries, and nothing it does not.

struct ICoreWinUIKeyFields {
public:
    // KeyRoutedEventArgs::Key(), as its integer. This is the Win32 VK.
    unsigned int virtualKey = 0;

    // KeyStatus().IsExtendedKey -- not optional, see ICoreWinUIEventMap.h on
    // VK_RETURN.
    bool extendedKey = false;

    // KeyStatus().WasKeyDown. This is QKeyEvent::isAutoRepeat().
    bool wasKeyDown = false;

    // ⚠ KeyRoutedEventArgs HAS NO MODIFIER PROPERTY. PointerRoutedEventArgs
    // has KeyModifiers(); its keyboard peer does not, and that is a real
    // asymmetry in the API rather than an omission here. The seat assembles
    // the mask from InputKeyboardSource::GetKeyStateForCurrentThread() and
    // passes it in -- ICoreWinUIEventArgs.cpp is where that happens.
    unsigned int keyModifiers = 0;
};
};

ICoreWinUIEventMap.h#

ICoreEssentials/UI/Backends/WinUI/Events/ICoreWinUIEventMap.h

The WinUI peer of ICoreInputEnumsVerify.cpp. (The planning row this came from is named in the .cpp, not here -- see the .cpp banner for why.)

WHY THIS IS A TABLE AND NOT A static_assert. ICoreInputEnums.h is pinned to Qt's numbering and ICoreInputEnumsVerify.cpp enforces that with static_assert against Qt's headers. A winui build HAS NO QT HEADERS, so the same trick is unavailable (§3): the correspondence is a decision, not an identity. It is therefore a lookup checked at RUNTIME, by testingLabs/tests/winui_event_map.

NO WINDOWS TYPES IN THIS HEADER. Every parameter is a plain integer, so the verify test -- and anything else above the backend -- can include this without windows.h and without the Windows App SDK. The .cpp is where VK_* is named. This is also why the numbers below can be checked on a machine

Declares no class of its own — see the file.