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.
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 a WPF application that is too onerous to rewrite wholesale in UWP. Some of the UWP controls would utilize SwapChainPanel and thus have C++/WinRT to manage DirectX. To determine the feasibility of implementing portions of the application in UWP and including them in WPF, I made a minimal sample app following Microsoft documentation that attempts to compose UWP controls in a WPF application targeting .NET Core 3.1.
<Window x:Class="WpfAppCore3._1.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:xh="clr-namespace:Microsoft.Toolkit.Wpf.UI.XamlHost;assembly=Microsoft.Toolkit.Wpf.UI.XamlHost"
Title="WPF App"
Height="500"
Width="800">
<StackPanel>
<xh:WindowsXamlHost InitialTypeName="UwpLib.ManagedGrid"
Height="225" />
<xh:WindowsXamlHost InitialTypeName="UwpLibNative.NativeGrid"
Height="225" />
</StackPanel>
</Window>
This works great for a managed control like UwpLib.ManagedGrid but UwpLibNative.NativeGrid does not load:
The debugger shows an exception:
System.BadImageFormatException: 'Bad IL format.'
That exception indicated to me a build configuration issue, but I think the application is set up correctly in that regard. Is this just not possible with XAML Islands today or have I made some configuration mistake in the sample app?
Update 1:
I discovered the "Windows Desktop Compatible" option and made sure that was set to "Yes". No change.
I'm using the release Version of Windows 8 and Visual Studio 2012 to create a WPF application with a Ribbon control. I choose the ribbon control that comes with WPF in .Net Framework 4.5.
My code to create the ribbon:
<RibbonWindow
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:WpfExperiments" x:Class="WpfExperiments.MainWindow"
Title="MainWindow" Height="350" Width="525" Icon="Test.ico">
<Ribbon>
<Ribbon.ApplicationMenu>
<RibbonApplicationMenu>
<RibbonApplicationMenuItem Header="Item 1"></RibbonApplicationMenuItem>
</RibbonApplicationMenu>
</Ribbon.ApplicationMenu>
<Ribbon.QuickAccessToolBar>
<RibbonQuickAccessToolBar>
<RibbonButton SmallImageSource="Test.ico" Label="Test"></RibbonButton>
</RibbonQuickAccessToolBar>
</Ribbon.QuickAccessToolBar>
</Ribbon>
But the problem is that it generates a window with a ugly style that doesn't match the windows 8 style:
Compare it to the explorer ribbon. The window title is centered (and has a different color) and the border size of the window is different. The style of the ribbon isn't the same, but I would be satisfied if I had the same ribbon style as MS Word (which is displayed correctly in Windows 8).
Does the ribbon control for WPF not support the new Windows 8 style? Or did I miss any setting?
Edit:
I started to edit the template in Blend (4.0, i don't have access to 5.0). After fixing some compilation errors (seems to be bugs in blend), I can run the application, but it looks like this:
But that isn't a good starting point for my changes...
The WPF Ribbon isn't a wrapper for a control offered by the operating system (like most of the Windows Forms controls) but built from scratch to have the look and feel of the ribbon at the time it was developed while being a control that is as flexible as other WPF controls (notice the support for template parts).
That said, it's a matter of the control not (currently) being updated to support the Windows 8 style. Given the number of templates for multiple controls that would have to be changed, as well as the need to be backwards compatible (and this is my speculation at this point) it may have been seen as not a priority when .NET 4.5 was released.
You might be able to change the theme yourself, but that looks like a massive undertaking, so it might be worth it to you to use a third-party control which already implements the Windows 8 ribbon style.
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
I've recently completed a fairly large (for one man) WPF project, and started coding something for fun. I was almost done with an app worthy of showing off to friends and colleagues, and I started playing with window sizes - manually resizing the window - just to see what would happen on various screens.
And what happened was - my window got corrupted for certain window sizes, especially at about 100x100 range. I got very confused, and started to remove parts from XAML, my code, everything. But the problem persisted.
Lastly, I created a brand new WPF project - I didn't even change the name - WpfApplication1 it's called. Surely, same artifacts appear. They are more subtle than those of the app, but still clearly visible.
So, what's going on?
I realize that the most obvious answer is to check my graphics card drivers, and I will try downgrading to an earlier release; but meanwhile note that my fairly large for one man-project works flawlessly, and it even uses DirectX shaders! And that I've installed the latest drivers just the week before, when I also reinstalled Windows.
I'm running Windows Server 2008 R2 with all patches, and vanilla Visual Studio with SP1 - no experimental compilers, or anything.
EDIT
The problem only happens on my machine, if I compile on my machine and run on another the problem is not evident.
The XAML of the bran new project is simply:
<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" Height="350" Width="525">
<Grid>
</Grid>
</Window>
EDIT 2
It seems that there's some kind of problem with the Latest Catalyst Driver - 11.8. Installing 11.7 fixed the issue as a workaround, as, well, expected. Mystery kinda solved, except for the why...
So does anyone know why the latest catalysts cause havoc with WPF?
Looks like this is a problem with Catalyst 11.8 - see:
http://forums.amd.com/game/messageview.cfm?catid=279&threadid=154834&enterthread=y
and
WPF: can't resize window without horrible visual effects
I notice it in VS 2010 as well as our own WPF apps. It's pretty horrible. Seems as though rolling back to Catalyst 11.7 fixes the problem.
It is probably a hardware problem with your graphics card.