Skip to content
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

Closed
zadjii-msft opened this issue Jul 25, 2019 · 3 comments · Fixed by #5485
Closed

When a dialog is open, the titlebar is the wrong color #2100

zadjii-msft opened this issue Jul 25, 2019 · 3 comments · Fixed by #5485
Assignees
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
Copy link
Member

related to #1625.

image

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.

@zadjii-msft 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
@zadjii-msft zadjii-msft added this to the Terminal v1.0 milestone Jul 25, 2019
@ghost 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
@DHowett-MSFT
Copy link
Contributor

Alternatively, we may want to disable the cutout when a dialog is up.

@DHowett-MSFT 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 zadjii-msft added Priority-3 A description (P3) v1-Scrubbed labels Jan 22, 2020
@beviu
Copy link
Contributor

beviu commented Feb 18, 2020

I have an idea. Would it be possible to replace the SetWindowRgn trickery by a completely transparent, invisible window that we put on top of the drag bar and that catches all of the mouse events? If this works then it means that the XAML can draw its own drag bar so this bug goes away and also it will allow for acrylic title bar.

I got this idea by using looking at the Settings UWP app's window using a tool called Spy++.
It looks like it does something similar to this (but not exactly this because the window's size is not exactly the same as the title bar's size) with a window called ApplicationFrameInputSinkWindow that only receive messages when I put my mouse on the drag bar:
image

I don't know if that would work but I might try to do it when I have free time. EDIT: I probably won't do it because I don't have free time but I'm leaving the idea here. Maybe it could be interesting.

@zadjii-msft zadjii-msft added Priority-2 A description (P2) and removed Priority-3 A description (P3) labels Feb 28, 2020
@beviu beviu mentioned this issue Mar 2, 2020
3 tasks
@ghost ghost added the In-PR This issue has a related PR label Mar 2, 2020
@DHowett-MSFT DHowett-MSFT self-assigned this Apr 24, 2020
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 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
@ghost
Copy link

ghost commented May 5, 2020

🎉This issue was addressed in #5485, which has now been successfully released as Windows Terminal Release Candidate v0.11.1251.0 (1.0rc1).:tada:

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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants