Context
Embedding a real launcher app (Fulcrum: topmost overlay panel, global hotkey, clipboard listener, window subclass) on Windows surfaced a friction point the current Windows scaffold doesn't cover: every one of those features needs the native HWND of the WinUI 3 host window.
The official interop routes are unstable in practice:
IWindowNative::get_WindowHandle requires interop headers whose cppwinrt projection shape moved between Windows App SDK releases, and needs extra projection includes that a plain pch.h scaffold does not set up.Microsoft.UI.Windowing.AppWindow covers presenter policy (topmost, taskbar) but still needs the interop bridge to get the HWND for RegisterHotKey, SetWindowSubclass, AddClipboardFormatListener, and SetWindowPos positioning.
Fulcrum ended up with a fragile workaround: FindWindowW(nullptr, L"Fulcrum") — finding its own window by a unique title (4 fix commits: windowing projections, HWND retrieval, Win32-first chrome, comctl32 linking).
Ask
Pick one (or both):
- Scaffold guidance: a documented, AppSDK-version-pinned snippet in the Windows template (
pch.h interop includes + cppwinrt projection notes in the vcxproj) showing the supported way to obtain the HWND.
- Runtime helper: a small API on the Windows runtime/system layer (e.g.
rivet::system::native_window_handle() or handing the HWND to OnLaunched) so apps never string-match their own window titles.
Happy to turn whichever direction you prefer into a PR — Fulcrum's working code is the reference.
Context
Embedding a real launcher app (Fulcrum: topmost overlay panel, global hotkey, clipboard listener, window subclass) on Windows surfaced a friction point the current Windows scaffold doesn't cover: every one of those features needs the native
HWNDof the WinUI 3 host window.The official interop routes are unstable in practice:
IWindowNative::get_WindowHandlerequires interop headers whose cppwinrt projection shape moved between Windows App SDK releases, and needs extra projection includes that a plainpch.hscaffold does not set up.Microsoft.UI.Windowing.AppWindowcovers presenter policy (topmost, taskbar) but still needs the interop bridge to get the HWND forRegisterHotKey,SetWindowSubclass,AddClipboardFormatListener, andSetWindowPospositioning.Fulcrum ended up with a fragile workaround:
FindWindowW(nullptr, L"Fulcrum")— finding its own window by a unique title (4 fix commits: windowing projections, HWND retrieval, Win32-first chrome, comctl32 linking).Ask
Pick one (or both):
pch.hinterop includes +cppwinrtprojection notes in the vcxproj) showing the supported way to obtain the HWND.rivet::system::native_window_handle()or handing the HWND toOnLaunched) so apps never string-match their own window titles.Happy to turn whichever direction you prefer into a PR — Fulcrum's working code is the reference.