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

Closed
opened 2026-01-30 23:09:14 +00:00 by claunia · 3 comments
Owner

Originally created by @zadjii-msft on GitHub (Jul 25, 2019).

Originally assigned to: @DHowett-MSFT on GitHub.

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.

Originally created by @zadjii-msft on GitHub (Jul 25, 2019). Originally assigned to: @DHowett-MSFT on GitHub. related to #1625. ![image](https://user-images.githubusercontent.com/18356694/61895322-04e81b80-aed8-11e9-8ecc-ce908f185e69.png) 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.
Author
Owner

@DHowett-MSFT commented on GitHub (Jul 25, 2019):

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

@DHowett-MSFT commented on GitHub (Jul 25, 2019): Alternatively, we may want to disable the cutout when a dialog is up.
Author
Owner

@beviu commented on GitHub (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.

@beviu commented on GitHub (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](https://user-images.githubusercontent.com/56923875/74767398-15eae680-5287-11ea-9440-1e8725b86684.png) 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.
Author
Owner

@ghost commented on GitHub (May 5, 2020):

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

Handy links:

@ghost commented on GitHub (May 5, 2020): :tada: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: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.11.1251.0 (1.0rc1)) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#2937