Wrong behavior with ShowTitleBar="False" in XAML control metrowindow settings
See original GitHub issueSetting ShowTitleBar to “False” in the controls metrowindow xaml results in the still shown title bar in the window. The dynamic binding in the demo works, but if it is set to “false” in the xaml control definition, the title bar is still there.
What steps will reproduce this issue?
You can check by replacing the MahApps.Metro.Demo.NET45
from
<Controls:MetroWindow x:Class="MetroDemo.MainWindow"
....
ShowTitleBar="ShowTitleBar="{Binding ShowMyTitleBar, Mode=OneWay}"
to
<Controls:MetroWindow x:Class="MetroDemo.MainWindow"
....
ShowTitleBar="False"
Expected outcome
TitleBar should be hidden when set to False in XAML definition.
Environment
- MahApps.Metro v1.6
- Windows OS 10
- Visual Studio 2017
- .NET Framework 4.61
Issue Analytics
- State:
- Created 6 years ago
- Reactions:3
- Comments:11 (1 by maintainers)
Top Results From Across the Web
Attaching Behaviour to MetroWindow fails and results in ...
I have a simple test application that shows a simple Mahapps MetroWindow with an attached Behaviour. The problem is when attaching the Behaviour...
Read more >MetroWindow
The MetroWindow can be used with different borders. You can change the behavior by using the BorderBrush , GlowBrush and BorderThickness properties. Normal ......
Read more >Quick Start
open up MainWindow.xaml · add this attribute inside the opening Window tag. (It's how you reference other namespaces in XAML): xmlns:Controls="clr-namespace: ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Then add your reaction through the reaction function. This project is maintained in the peoples spare time, so don’t add pressure on them by saying “Really need to see a fix and a NuGet release”.
If you think it takes too long to fix the issue then jump in and fix the issue.
Regarding priority, it impacts you but by far not everyone else. It only impacts people using this particular feature.
@batzen No, I am only highlighting this is a very handicapping issue and, regarding the impacted users and the fact it has been living for a long time (release > 1.5), it should be considered as highly prioritized. No more, no less.