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.
Related
I have a WPF application which is giving me a very very annoying error
System.Runtime.Remoting.RemotingException
[12068] Designer process terminated unexpectedly!
The number between [] changes each time
The XAML is very simple
<UserControl x:Class="STC.Reports.ReportGenerator.Views.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
</UserControl>
This has wasted me hours and hours
Does anyone know anything that could help?
I cant get any more information than that above
Even though I have told VS to break on these Exceptions it doesnt
I have also tried to attach another VS and that makes no difference
I have repaired my installation of VS (2012 Professional)
I have also updated to Update 3
This is even happening when I create a brand new WPF application
Everything seems fine initially, then VS just hangs and the remoting error occurs
Paul
What kind of message are You getting?
If it is a Messagebox when You try to use designer - it is a known issue since VS2010 as far as I remember. It is frequently caused by a video card or its driver, so the easiest way is trying to update your video driver or use some older version. Sometimes that help.
The other way is not to use built-in designer. As for me, I wite pure xaml and it seems to be more convenient and faster way of development. Or, if You like visual UI - You may use Blend. AFAIK it is a part of VS2012 now.
I had this error occur for all windows/controls in a project, even if they were brand new empty windows. I had a markup extension causing a design-time exception (with no indication of this from Visual Studio) and I would get this designer error if I used the markup extension in any project resource dictionaries.
Old post but might be useful for future developers who run into this kind of problem.
I had this exact behaviour. Turned out to be a problem related to my viewmodel. At runtime everything works, but at design time VS will try to load the viewmodel standalone and things got haywire. My viewmodel depended on some global object which I created elsewhere at application startup. Loading the viewmodel standalone creates a exception since the global object was missing.
Quite easy to detect actualy. Just test your viewmodel by instantiating it yourself from code. If it fails VS won't be able to run the designer as well and as you see VS unfortunately won't tell you what happened.
When selecting "cut" from the TexBoxes' context menu, it works as if I did a "copy".
Same goes if I do a control-x, it simply copies instead of cutting.
Here is my simple dimple xaml
<Window x:Class="Window2"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="Window2">
<TextBox/>
</Window>
Anybody have any idea what might be wrong?
ENVIRONMENT:
windows 7 Pro 64 bit
.net 4.5
in my situation, the culprit in the end was vnc viewer
you may find the following interesting or helpful
https://connect.microsoft.com/VisualStudio/feedback/details/798501/textbox-cut-bug-in-wpf
hope this helps you!
I just had this issue, and found the issue was due to Notepadd++'s Clipboard History feature. Once I closed the program, cutting worked perfectly.
It is definitely caused by external programs doing clipboard interference (probably incorrectly), as it was Notepad++ for me, and VNC for #Yisman. It should be considered a WPF bug though, since any non-WPF application can cut perfectly with Notepad++'s Clipboard History running.
My best guess, after looking at the details from the Connect post, is that the copy part of the cut command throws an exception, but throws is after adding the text to the clipboard. Other programs will still do the delete portion of the cut command, where WPF will skip it. This is reasonable, as it probably assumes it wasn't added to the clipboard, since the copy failed, but doesn't work well in this case.
I had the some issue using VS2015 on Windows 10 pro 64 bit as a Virtualbox 5.1.6 guest on a OSX host. The "problem" was the Virtualbox Shared clipboard between the guest and a host OS (Guest To Host).
I just spent several hours on an issue when using VS2012, WPF 4.5 and design-time data, specifically the DesignInstance attribute.
Goal: I wanted to have design-time data support in my WPF project (MVVM-based), both in VS2012 and Blend, and I could not for the life of me make the MVVMLight approach work consistently.
So I tried to change to "just" using the built-in support for design-time data, using the markup extension provided with Blend.
Problem: Consider the following code:
<Window x:Class="Nova.View.AlertsView"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:local="clr-namespace:Nova.View"
xmlns:vm="clr-namespace:Nova.ViewModel"
mc:Ignorable="d"
DataContext="{Binding Alerts, Source={StaticResource Locator}}"
d:DataContext="{d:DesignInstance vm:DesignAlertsViewModel, IsDesignTimeCreatable=True}"
... />
Both VS2012 and Blend reports "the name DesignAlertsViewModel does not exist in the namespace clr-namespace:Nova.ViewModel", even though intellisense resolves it just fine, and you have checked a thousand times that the namespace and class name are both correct.
I ran into this error myself in VS2013 then found this question. After searching more, I found an answer that helped me solve it.
instead of
d:DataContext="{d:DesignInstance vm:DesignAlertsViewModel, IsDesignTimeCreatable=True}"
use
d:DataContext="{d:DesignInstance d:Type=vm:DesignAlertsViewModel, IsDesignTimeCreatable=True}"
I was using "...d:DesignInstance Type=vm:..." and that displays the same error described above. As soon as I add "d:" everything works.
Here is the thread I found that helped.
https://stackoverflow.com/a/21690404/2892400
Check if the "Platform target" in your build configuration is set to "AnyCPU". My was set to "x64", so the designer was complaining about the missing type.
VS is running in 32 bit so maybe there is an issue with executing code from 64 bit assemblies.
I found the solution when trying to open my UserControl in "Blend for Visual Studio". It displayed an neat exception to me.
P.S.: After using the accepted answer: Use "d:Type=vm:DesignAlertsViewModel" instead of "vm:DesignAlertsViewModel" my control was visible, but no example data was displayed.
Workaround: Make sure that the design-time data class is in the same namespace as the View itself. Once I moved my DesignAlertsViewModel to the View namespace, both the VS2012 and Blend designer immediately started working with the design-time data.
Update: This is a workaround for now, until I get to the bottom of the issues. However, in my case, this is the only way to make design-time data work consistently. Of course, if you go down this route you change the class names since - clearly - the DesignAlertsViewModel is no longer a view model. It is now simply a POCO containing design-time data. So perhaps AlertsDesignData would be a better name. I'm not overly happy with the fact my design-time data lives under my View namespace, but it works.
I also encourage you to take a look at Laurent's article from MSDN Magazine, April 2013. I like this approach, since it exercises the MVVM pattern a lot more: The design time data service/provider is injected via IOC, so your view models will get "exercised" even at design time.
Update 2: After spending yet another 4 hours on this, I think the jury is still out on which approach is the better: Should we go with simple POCO data classes or the MVVMLight approach, using IOC for design-time data services? The former is simple and requires less code, the latter is more true to the MVVM approach, and exercises the real view models to some degree and could possibly reveal some bugs along the way.
Also, I did have to restart VS a couple of times during my refactoring to the MVVMLight approach - design-time data simply disappeared and came back after a VS restart. However, right now it seems stable enough, and I cannot pinpoint this any further.
I've found that DesignInstance is not working in my .NET 3.5 and .NET 4.0 projects, whereas it works in >= .NET 4.5 project (the projects are the same, they share the same files by using links).
I've been trying to use the Extended WPF Toolkit so that I can make use of the RichTextBoxFormatBar but I seem to be going round in cirlces. Despite trying several examples on here and other sites I keep getting the same error messages:
The attachable property 'FormatBar' was not found in type 'RichTextBoxFormatBarManager'.
The type 'toolkit:RichTextBoxFormatBar' was not found. Verify that you are not missing an assembly reference and that all referenced assemblies have been built.
I'm new to WPF so I'm know it's something I'm not picking up on rather than a bug, can anyone tell me what I'm doing wrong and save my sanity?
<UserControl x:Class="TestWPF_Richtextbox.UserControl1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:toolkit="http://schemas.xceed.com/wpf/xaml/toolkit"
mc:Ignorable="d"
d:DesignHeight="300" d:DesignWidth="300">
<Grid>
<RichTextBox>
<toolkit:RichTextBoxFormatBarManager.FormatBar>
<toolkit:RichTextBoxFormatBar />
</toolkit:RichTextBoxFormatBarManager.FormatBar>
</RichTextBox>
</Grid>
</UserControl>
EDIT: Both the library and the project are .Net 4. The version of the WPFToolkit.Extended.dll is V.1.6.0.0.
My own stupid fault.
I'd forgotten to unblock the DLL when I downloaded it as per the instructions which say that after downloading the ExtendedWPFToolkit_Binaries.zip you should then right click on it, select "Properties" and then "Unblock".
Hopefully this post will help someone else who has made the same mistake.
I'm hardly a rookie - but had the same issue.
Frankly I've never heard of unblocking a .zip file. Like most people I just skimmed the instructions, after all I know how unzip a file - or so I thought.
I had fought with extended toolkit 1.9.0 for two hours because my app would compile, run and work, but VS12 designer couldn't render the window. THen I saw the above post about unblocking the zip before expanding. Thought to myself "whiskey tango foxtrot" is this guy talking about. But I was desperate, so I closed VS. Deleted my expanded files. This time did the unblock. THen expanded into the very same locations. Restarted Visual Studio and to my amazement the designer now renders the controls and don't complain about the WatermarkTextBox not being in the namespace etc.
Really a humbling experience about reading the directions more closely.
This same thing happened to me and I eventually figured out it was either because I had the dll or the solution stored on the network instead of my local computer. I moved both to the local computer and it started working.
I am using a base Window class in a WPF project. In the code behind C# file the assembly to the base type is referenced and fine. In the XAML is looks like this:
<MyNamespace:WindowBase x:Class="MyNamespace.Applications.UserInterface.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:MyNamespace="clr-namespace:MyNamespace.Somewhere;assembly=MyNamespace.Common"
Title="MainWindow" Height="350" Width="525">
<Grid>
</Grid>
The solution compiles fine and I can run it. I just can't use the designer in VS 2010. It throws the following exception: The type'MyNameSpace:WindowBase' was not found. Verify that you are not missing an assembly reference and that all referenced assemblies have been built.
Well. they have been. I can't understand what this issue is. This particular base class is used in other projects just fine. I grabbed it for a new project and I can't use the designer. Very frustrating.
Found this problem just recently (this answer upgraded from a comment).
If you copy the dll from a network path, you must right click on the file in Windows Explorer, select Properties, then 'unblock'; there is a hidden NTFS stream associated with the file, and many files when you download from the 'net or copy from a network path, for security reasons.
Only the designer complains, yet the project builds and runs fine: weird isn't it?!
Whenever the designer is acting up against me - the first thing I do is clear the obj-folders in the project and rebuild. Sometimes they seem to go out of sync for some reason (usually when I'm drag-dropping a lot of files and renaming visual items).
I dont't know if its the same issue but in VS2008 I tried to make abstract UserControls but had to change this because the designer didnt't support any abstract base classes (however the solution was compilable and also worked as excpected).
Fixed. The library that contained my base class resided on a drive on the network that I did not have permissions to. That seemed to have no affect on VS 2008 as it worked, but VS 2010 apparently took exception to that when the designer tried to load it. Weird.