-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When a dialog is open, the titlebar is the wrong color #2100
Labels
Area-User Interface
Issues pertaining to the user interface of the Console or Terminal
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Needs-Tag-Fix
Doesn't match tag requirements
Priority-2
A description (P2)
Product-Terminal
The new Windows Terminal.
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Comments
zadjii-msft
added
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Area-User Interface
Issues pertaining to the user interface of the Console or Terminal
Product-Terminal
The new Windows Terminal.
labels
Jul 25, 2019
ghost
added
the
Needs-Triage
It's a new issue that the core contributor team needs to triage at the next triage meeting
label
Jul 25, 2019
29 tasks
Alternatively, we may want to disable the cutout when a dialog is up. |
DHowett-MSFT
removed
the
Needs-Triage
It's a new issue that the core contributor team needs to triage at the next triage meeting
label
Jul 29, 2019
zadjii-msft
added
Priority-2
A description (P2)
and removed
Priority-3
A description (P3)
labels
Feb 28, 2020
4 tasks
DHowett-MSFT
pushed a commit
that referenced
this issue
Apr 24, 2020
Also known as "Kill HRGN II: Kills Regions Dead (#5485)" Copying the description from @greg904 in #4778. --- 8< --- My understanding is that the XAML framework uses another way of getting mouse input that doesn't work with `WM_SYSCOMMAND` with `SC_MOVE`. It looks like it "steals" our mouse messages like `WM_LBUTTONDOWN`. Before, we were cutting (with `HRGN`s) 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: 1. it's hard to keep track of the right color: if a dialog is open, it will cover the whole window including the drag bar with a transparent white layer and it's hard to keep track of those things. 2. we can't do acrylic with GDI 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_LBUTTONDOWN` messages. --- >8 --- Dustin's notes: I've based this on the implementation of the input sink window in the UWP application frame host. Tested manually in all configurations (debug, release) with snap, drag, move, double-click and double-click on the resize handle. Tested at 200% scale. Closes #4744 Closes #2100 Closes #4778 (superseded.)
ghost
added
Needs-Tag-Fix
Doesn't match tag requirements
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
and removed
In-PR
This issue has a related PR
labels
Apr 24, 2020
🎉This issue was addressed in #5485, which has now been successfully released as Handy links: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Area-User Interface
Issues pertaining to the user interface of the Console or Terminal
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Needs-Tag-Fix
Doesn't match tag requirements
Priority-2
A description (P2)
Product-Terminal
The new Windows Terminal.
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
related to #1625.
This one's tricky - the Background of the TabRow doesn't actually change here, it's just being combined with the overlay of the ContentDialog. We'd have to compose that color ourselves in the NonClientWindow class.
The text was updated successfully, but these errors were encountered: