Hi,
this is a follow-up to our discussion in my proposal here microsoft/microsoft-ui-xaml#10050 (comment). I'm replying here to avoid it getting side-tracked too much ;-)
Thanks at lot for pointing me at this sample. I had seen it before and didn't expect it to be working and it actually does work on Win11 and even with pointer input messages getting properly directed to the control.
I've been MS MVP for Windows API from 2003-2011 and thought I had tried everything. So, especially the outcome of further analysis has turned out to be quite surprising: It's all and only about the WS_EX_LAYERED window style.
(not about ATL, not about the AtlAxWin window class, not about the subclassing of the child window, etc.)
The underlying behavior is as follows
- Inside a XAML island window layering is generally ignored. Input events (keyboard, mouse, pointer) are being captured directly (without those messages going through any of the child windows' message loops)
- Except when there is a window (inside the XAML island), which has the
WS_EX_LAYERED style and is above the DesktopChildSiteBridge window: For the area which is covered by this window, the internal input handling is disabled and and works like normal on Windows
- The
WS_EX_LAYERED window itself doesn't play any other role:
- The windows which you want to receive input do not need to be children of the
WS_EX_LAYERED window
- They can even be above it
Example:

The "Static" window has style WS_EX_LAYERED (and no content). It's sole existence causes the (hWnd-based) WebView2 to receive input events in the area it covers.
While I'm glad to have found a solution workaround eventually, there's one question remaining: "WTF Microsoft???" WS_EX_LAYERED has nothing to do with input handling (and really shouldn't).
Hi,
this is a follow-up to our discussion in my proposal here microsoft/microsoft-ui-xaml#10050 (comment). I'm replying here to avoid it getting side-tracked too much ;-)
Thanks at lot for pointing me at this sample. I had seen it before and didn't expect it to be working and it actually does work on Win11 and even with pointer input messages getting properly directed to the control.
I've been MS MVP for Windows API from 2003-2011 and thought I had tried everything. So, especially the outcome of further analysis has turned out to be quite surprising: It's all and only about the
WS_EX_LAYEREDwindow style.(not about ATL, not about the
AtlAxWinwindow class, not about the subclassing of the child window, etc.)The underlying behavior is as follows
WS_EX_LAYEREDstyle and is above the DesktopChildSiteBridge window: For the area which is covered by this window, the internal input handling is disabled and and works like normal on WindowsWS_EX_LAYEREDwindow itself doesn't play any other role:WS_EX_LAYEREDwindowExample:
The "Static" window has style
WS_EX_LAYERED(and no content). It's sole existence causes the (hWnd-based) WebView2 to receive input events in the area it covers.While I'm glad to have found a
solutionworkaround eventually, there's one question remaining: "WTF Microsoft???"WS_EX_LAYEREDhas nothing to do with input handling (and really shouldn't).