API — ICoreEssentials/UI/Backends/WinUI
The public contract of 3 header(s) under ICoreEssentials/UI/Backends/WinUI — 0 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.
| Header | Defines | Declarations | Bases |
|---|---|---|---|
ICoreWinUIDispatcher.h | — | 0 | — |
ICoreWinUINativeHandleAccess.h | — | 0 | — |
ICoreWinUIWake.h | — | 0 | — |
ICoreWinUIDispatcher.h#
ICoreEssentials/UI/Backends/WinUI/ICoreWinUIDispatcher.h
Backend-internal: the one DispatcherQueue this process has, and who owns it.
The application seat creates it on the thread that constructs ICoreApplication, and ICoreMainThread and ICoreUiTimer both need to reach it. Neither of them owns it and neither may create a second one, so this is a getter and nothing else.
⚠ IT CAN BE EMPTY, AND THAT IS THE WHOLE REASON THIS HEADER SAYS SO OUT LOUD. Before ICoreApplication is constructed there is no queue, exactly as QCoreApplication::instance() is null before the Qt application exists. ICoreMainThread's header specifies the behaviour for that window -- "before the application object exists there is no queue to hand the callable to; post() then runs it synchronously rather than dropping it" -- so every caller here MUST branch on null rather than assume.
Declares no class of its own — see the file.
ICoreWinUINativeHandleAccess.h#
ICoreEssentials/UI/Backends/WinUI/ICoreWinUINativeHandleAccess.h
The one place this backend turns an ICoreNativeHandle back into the thing it points at. Backend-private: include it from a .cpp inside UI/Backends/WinUI/ and nowhere else.
(The planning row is named in the .cpp rather than here: the docs generator lifts a header's comments onto a generated API page, which is read by people who cannot open this repository, so a board filename in one is noise to every reader it reaches.)
⚠ THE CAST IS UNCHECKED AND THAT IS THE WHOLE POINT OF CENTRALISING IT. ICoreNativeHandle is void*, so nothing in the type system says the handle a caller passes was produced by THIS backend. The Qt seat has the identical hazard and answers it the identical way -- one inline in one header, so there is one line to read when a handle turns out to be the wrong kind,
Declares no class of its own — see the file.
ICoreWinUIWake.h#
ICoreEssentials/UI/Backends/WinUI/ICoreWinUIWake.h
Backend-internal. Not part of any public surface, and it names no Windows type, so any seat in this backend can include it without dragging in windows.h or the Windows App SDK.
WHY IT EXISTS. ICoreApplication::tick(waitMs) blocks in MsgWaitForMultipleObjectsEx, which ends its wait for INPUT TO THIS THREAD'S MESSAGE QUEUE and for nothing else. The header's contract is "sleeps until something happens or that long passes, WHICHEVER COMES FIRST", so anything that gives the application work to do must also make the queue non-empty, or a tick(500) with work already pending sits out its whole timeout.
A DispatcherQueue post does this by itself -- a tick(4000) was measured cut short by a cross-thread TryEnqueue -- because CoreMessaging delivers callbacks as messages. What does NOT do it by itself is a change to plain
Declares no class of its own — see the file.