Terminal.Gui: Border color doesn't change when changing color scheme
Describe the bug The border color of some Views (for example FrameView or Window) doesn’t change when changing color scheme while the application is running.
To Reproduce Steps to reproduce the behavior:
- Create a new application using Terminal.Gui
- Add a new Window and add a FrameView and a Button into the Window
- Change the ColorScheme on the button click
- Run the application and see, that when clicking the button, the color of everything except the border changes
Expected behavior The border foreground and background changes according to the new ColorScheme
Screenshots
Before button click:
After button click:
Desktop (please complete the following information):
- OS: Windows 11
- Version 1.12.1 of Terminal.Gui
Aditional information The code I use to set up this example:
Application.Init();
var win = new Window("Test");
var frame = new FrameView()
{
X = 5,
Y = 10,
Width = Dim.Fill() - 5,
Height = Dim.Fill() - 10,
Title = "Test Frame",
};
var button = new Button(50, 0, "Change theme");
button.Clicked += () => Clicked();
win.Add(button, frame);
Application.Top.Add(win);
Application.Run();
Application.Shutdown();
void Clicked()
{
win.ColorScheme = new ColorScheme
{
Disabled = Attribute.Make(Color.White, Color.Black),
Normal = Attribute.Make(Color.Cyan, Color.Black),
HotNormal = Attribute.Make(Color.White, Color.Black),
Focus = Attribute.Make(Color.White, Color.Black),
HotFocus = Attribute.Make(Color.White, Color.Black),
};
}
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 19
Commits related to this issue
- Fixes #2686. Border color doesn't change when changing color scheme. — committed to BDisp/Terminal.Gui by BDisp a year ago
- Fixes #2686. Border color doesn't change when changing color scheme. (#2687) * Fixes #2686. Border color doesn't change when changing color scheme. * Fix issue that was preventing unit test from r... — committed to gui-cs/Terminal.Gui by BDisp a year ago
I will quickly clone the repo and test this locally
@BDisp I know about this workaround, I just think that I shouldn’t need to us it.