In Windows 8 RTM with VS2012 RTM I noticed my WPF app was giving me deformed radio buttons so I decided to create a sample to see if I was doing something wrong.
Here's the entire XAML App :
<Window x:Class="WpfApplication1.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" SizeToContent="WidthAndHeight">
<Grid>
<StackPanel Margin="20">
<RadioButton Content="Option 1" GroupName="1"/>
<RadioButton Content="Option 2" GroupName="2"/>
<RadioButton Content="Option 3" GroupName="3"/>
</StackPanel>
</Grid>
</Window>
Here I have the DPI settings set to 100%, which is actually NOT the default in Windows 8 (well at least for my 1920x1200 screen it isn't). You'll see the radio buttons are perfect.
This is the same exact application with DPI settings at 125% which is the default DPI for my screen resolution.
Here's 150%
You can see the inner circles aren't centered within the outer circle and it looks TERRIBLE. System applications with radio buttons are fine - but my WPF 4.5 app is not. Once again this sample app is 100% RTM bits and from scratch under Win 8.
Is it just all broken or is there a way to fix this (apart from insisting people put 100% DPI scaling).
Was really hoping Win8 would have gone a long way for high res screens and scaling issues like this, but something simple is badly broken out of the box :-(
Edit: filed connect bug https://connect.microsoft.com/VisualStudio/feedback/details/758368/radio-button-rendering-is-incorrect-on-windows-8-with-125-dpi-scaling-set
Edit: 8/29/12:
The WPF team has recently reviewed this issue and will not be
addressing this issue as at this time the team is focusing on the bugs
impacting the highest number of WPF developers. If you believe that
this was resolved in error, please reactivate this bug with any
necessary supporting details.
Everything in WPF is styled. In the case of the default system styles they sometimes, in my own experience, have little issues like this. A simple fix, to confirm it is the style and not the OS itself is to restyle the control yourself and see if that fixes it.
You can find the original style by looking at this question. These will help you rebuild and / or fix the issue
You could try put the stackpanel in a viewbox .. maybe
Related
I am building a WPF library that connects windows.
In the example the windows have the following properties:
<Window ...
Height="150"
Width="200"
WindowStyle="None"
ResizeMode="CanResize"
Background="#222222"
AllowsTransparency="False">
<WindowChrome.WindowChrome>
<WindowChrome CaptionHeight="1"
CornerRadius="0"/>
</WindowChrome.WindowChrome>
I use Chrome window because I need to remove the title and be able to resize.
Everything is working well except there are noticeable gaps between windows, although I want to connect them exactly next to each other.
Example layout with 2x magnifier:
https://prnt.sc/26if2vs
What does it cause, can I handle it inside the app, or it caused by the Windows system?
I have annoying appearance differences between Windows 10 devices and Windows 7 devices.
I am using WindowStyle="None" and DockPanel directly inside my Window element.
What I don't get is why there is still a border? Why are the borders on buttons, textboxes, comboboxes, etc. rounded?
It seems this is related to Aero. Is there a way I can stop my application from using Aero? I'm assuming there is another presentation framework related to Windows 10 but do not know what it is called to force it.
Would a BorderBrush be the easiest way to resolve this?
<Window x:Class="CBD.Presentation.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:CBD.Presentation"
Title="CBD" Height="760" Width="944" WindowStartupLocation="CenterScreen"
WindowStyle="None" SizeChanged="Window_SizeChanged" MinWidth="944" MinHeight="760"
Icon="favicon.ico">
<DockPanel x:Name="Root_Window" Background="Black">
<!--Application stuff here -->
</DockPanel>
</Window>
Windows 7 display:
Windows 10 display:
Everything still functions properly but the way some textboxes and buttons are setup, parts of letters are missing.
I think both these is something a lot of people are going to stumble upon when they really start customizing the style of their applications. There's some well established shortcuts to both problems, such as using existing style/libraries for WPF:
There's a few common Window and style libraries I see:
MahApps.Metro is a great library I've used for a long time for getting clean windows and interfaces (especially with 'dark' themes some customers love).
Modern UI. Little personal experience, but it's similar in that it has more modern window designs, as well as a big style set. I've seen it used frequently.
Elysium. Again, not much experience, but seems active. I've not seen it used as much as the other two.
These, of course, include a lot of other Metro theming. There are other theme packs available, I've found the Material Design In XAML Toolkit great if a client want's a modern design (Also recognizable, being from Google).
It looks like you're making your style from scratch, but the above might still be useful for you to simply use for the windows. If you want to go at it yourself there's a lengthy discussion with lot's of answers here.
For the curved corners, as discussed in the comments, this is as a result of WPF's default behavior on different operating systems. It attempts to select a default style to blend in best with the current operating system. For most applications that just use the default theme, this doesn't often matter.
When you're styling everything yourself though, it really plays havoc with what you have manually configured, because some properties that work well with the theme you set things up on might be different - like the rounded corners.
There's two options.
Explicitly set all the properties, so it looks exactly how you want it. Doing this means that even if the 'base' theme changes, it will still look good. This is how those libraries above do things - they define a style completely. Problem is you will have to test it on the different themes manually and it's a bit of work.
Manually set the base theme. (Can also be used for testing in option 1!) You can override which theme your app uses manually rather than letting it use the default for the operating system in much the same way you apply other custom themes, or maybe your own:
<App.Resources>
<ResourceDictionary Source="/PresentationFramework.Aero, Version=3.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
ProcessorArchitecture=MSIL;component/themes/aero.normalcolor.xaml"/>
</App.Resources>
For some reason the above would not appear as code unless encased in quotes...
recently i had tried to make task-bar invisible in maximize mode but unfortunately nothing worked.
i had some research over MSDN and stack overflow and most of them said make window border equal to none and maximize window.but it didn't worked.
BTW: i am using Metro-window and it has a hide task-bar functionality by itself.but it didn't worked either.
My experience on Windows 8.1 is that setting WindowStyle="None" WindowState="Maximized" (as most people say) is not enough.
To hide taskbar I had to set ResizeMode="NoResize"
I have noticed (on my Vista 64bit machine) that a video being shown in a WPF MediaElement has different colors than when being played in Windows Media Player. Inside the MediaElement, the video has a slightly desaturated look with lower contrast.
The videos I have tried so far are WMV videos that were produced by different people with different tools, so I'd rule out problems with the video material. All "Video Settings" sliders in Windows Media Player (Hue, Saturation, Brightness, Contrast) are on their default values.
That's why at first I suspected an issue in my software which is making extensive use of animated opacity and content being placed over the video.
But I have been able to reproduce the behavior with a simple test program where the XAML looks like this:
<Window x:Class="MediaElementTest.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Window1" Height="300" Width="300">
<MediaElement Source="D:\Test\Video.wmv" />
</Window>
Am I doing something wrong? Is there a workaround?
Since I'm pretty sure the MediaElement will use the VMR9 on XP and the EVR on Vista, you might be seeing the behavior explained here
I'm guessing Windows Media Player uses either the VMR7 or default Video Renderer so it doesn't have that behavior. OR Microsoft has compensated in some way.
If you video card supports it, there are sometimes some software options to fix this.
If you have an NVidia card, goto the NVidia control panel. Click on "Video" in the options tree. Select the monitor and click the "With NVidia Settings" radio button. In the advanced tab, select "Dynamic Range 0-255".
Thats it!
As a follow up to my previous question, I am wondering how to use transparent windows correctly. If I have set my window to use transparency, the UI will occasionally appear to stop responding. What is actually happening is that the UI simply is not updating as it should. Animations do not occur, pages do not appear to navigate; however, if you watch the debugger clicking on buttons, links, etc.. do actually work. Minimizing and restoring the window "catches up" the UI again and the user can continue working until the behavior comes back.
If I remove the transparent borders, the behavior does not occur. Am I doing something wrong or is there some other setting, code, etc... that I need to implement to work with transparent borders properly?
Here is my window declaration for the code that fails.
<Window x:Class="MyProject.MainContainer"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="WPF APplication" Height="600" Width="800"
xmlns:egc="ControlLibrary" Background="{x:Null}"
BorderThickness="0"
AllowsTransparency="True"
MinHeight="300" MinWidth="400" WindowStyle="None" >
And the code that does not exhibit the behavior
<Window x:Class="MyProject.MainContainer"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="WPF Application" Height="600" Width="800"
xmlns:egc="ControlLibrary" Background="{x:Null}"
BorderThickness="0"
AllowsTransparency="False"
MinHeight="300" MinWidth="400" WindowStyle="None" >
Are you using .NET 3.0, or .NET 3.5 on Windows XP SP2? If so, this is a known problem with the transparent window API that has been fixed in .NET 3.5 and SP3 of XP (and I think SP1 of Vista). Basically when you set the AllowsTransparency to True, the WPF pipeline has to render in software only mode. This will cause a significant degradation in performance on most systems.
Unfortunately, the only thing you can do to fix this is to upgrade to .NET 3.0 SP1 (included in .NET 3.5), and install the appropriate service pack for Windows. Note that the transparent windows are still slower, but not nearly as bad. You can find a more in-depth discussion here.
I think that I've finally found a workaround. From everything I've read this problem should not be occurring with XP SP3 & .NET 3.5 SP1, but it is.
The example from this blog post shows how to use the Win32 API functions to create an irregular shaped window, which is what I"m doing. After reworking my main window to use these techniques, things seem to be working as expected and the behavior has not returned.
It is also of note that the reason the author recommends this method is due to performance issues with WPF and transparent windows. While I believe it may be better in .NET 3.5 SP1 that it was, this was not that hard to implement and should perform better.
I am running on Windows XP Pro SP3 and using .NET 3.5 SP1. I have also verified that the project is targeting version 3.5 of the framework.