Replace the HRGN-based titlebar cutout with an overlay window #5485
Conversation
…background during resize
…nal into dev/duhowett/kill_hrgn_4778
* Don't recreate the window every time; it's possible to use SetWindowPos and show/hide it on-demand * WIL-ize and document a couple things * make the class registration a static inline * make class reg/creation happen as part of MakeWindow * remove the entire tabview color key (let it fall back to the actual color specified in MUX)
| // Get the cursor position from the _last message_ and not from | ||
| // `GetCursorPos` (which returns the cursor position _at the | ||
| // moment_) because if we're lagging behind the cursor's position, | ||
| // we still want to get the cursor position that was associated | ||
| // with that message at the time it was sent to handle the message | ||
| // correctly. |
| POINT screenPt = clientPt; | ||
| if (ClientToScreen(window, &screenPt)) | ||
| { | ||
| const auto parentWindow{ GetAncestor(window, GA_PARENT) }; |
There was a problem hiding this comment.
This is just a formality, right? Like, we know this is going to just return GetWindowsHandle() right?
There was a problem hiding this comment.
So the trick here is this isn’t a member function and doesn’t have access to this
There was a problem hiding this comment.
Oh derp, thanks for clearing that up
There was a problem hiding this comment.
Is it worth commenting to that effect?
There was a problem hiding this comment.
You know, given our plans for this it might be better to just make this a member and do the window data pointer thing anyway.
|
I tested fullscreen, but not from maximized. I’ll add it to the list. |
|
@zadjii-msft tested, passed:
|
DHowett-MSFT
changed the title
|
🎉 Handy links: |
|
How does this work with Tablet Mode? Does it still use acrylic in the titlebar? |
|
This changes nothing about tablet mode. |
|
Did these changes make it into the release? Do they exist at the moment? I do not see acrylic in versions 1.4+ Best regards, |
|
@rovecode this change did not add acrylic to the title bar. This change removed a technical roadblock to having acrylic in the title bar. |
|
@DHowett. OK. But acrylic in the title bar is not planned? |
Copying the description from the inimitable @greg904 in #4778.
Summary of the Pull Request
My understanding is that the XAML framework uses another way of getting mouse input that doesn't work with
WM_SYSCOMMANDwithSC_MOVE. It looks like it "steals" our mouse messages likeWM_LBUTTONDOWN.Before, we were cutting (with
HRGNs) the drag bar part of the XAML islands window in order to catch mouse messages and be able to implement the drag bar that can move the window. However this "cut" doesn't only apply to input (mouse messages) but also to the graphics so we had to paint behind with the same color as the drag bar using GDI to hide the fact that we were cutting the window.The main issue with this is that we have to replicate exactly the rendering on the XAML drag bar using GDI and this is bad because:
So I found another method, which is to instead put a "drag window" exactly where the drag bar is, but on top of the XAML islands window (in Z order). I've found that this lets us receive the
WM_LBUTTONDOWNmessages.PR Checklist
HRGNfor the titlebar #4744. Closes When a dialog is open, the titlebar is the wrong color #2100. Closes Kill HRGN #4778 (superseded.)HRGNfor the titlebar #4744Detailed Description of the Pull Request / Additional comments
Picture's worth a thousand words.
Available with this PR:
Available after version 1, if we so desire:
Validation Steps Performed
DH: Tested manually in all configurations (debug, release) with snap, drag, move, double-click and double-click on the resize handle. Tested at 200% scale.