Update:
Screenshot http://farm4.static.flickr.com/3277/3048788466_661e8e5e78_b.jpg
To reproduce:
Get this sample project from Silveright.net - http://download.microsoft.com/download/5/9/2/5922d533-7ed5-4065-a138-ce3d9ca266e5/4-UserControls_Source_CS.zip
Open the UserControlDemo Solution. Then on Line 9 of Page.xaml, you'll see the error.
http://download.microsoft.com/download/5/9/2/5922d533-7ed5-4065-a138-ce3d9ca266e5/4-UserControls_Source_CS.zip
I'm creating a User Control in Silverlight 2 using this as my guide.
The problem is that when I use my User Control in Page.xaml, the XAML canvas shows this error: "Unknown attribute Name on element ... ."
Due to this error, I can no longer preview my XAML canvas. The strange thing is that the project still builds and renders my User Control beautifully.
Upon investigating the problem, I've found out the the cause of the problem was that my User Control was using a Style which is a StaticResource. When I remove this Style Property, the error in my Page.xaml XAML file disappears.
This error has been talk about in other online threads but unfortunately to no resolve.
I'm using the latest release and service packs of Visual Studio 2008 and Silverlight 2.
Is there something wrong with what I'm doing or is this a VS/Silverlight bug?
Thanks in advance!
In my experience the Visual Studio XAML designer, especially with Silverlight, will crap out for pretty much anything. I can't open a XAML file without all sorts of those mysterious errors and when it does render in the designer, it's not usually very useful.
Related
When working w/ a WinForm project in VS.NET 2015, our team has noticed that the mere act of opening a .VB form in the designer view (default action when double-clicking the file in Solution Explorer) will cause VS to modify many object properties in the "Windows Form Designer generated code" section of the actual .VB code-behind. It seems to be limited to the .Size and .Location properties for sometimes dozens or more of UI objects, always changing their X,Y coords just slightly.
Mind you we don't perform any action to drive this -- simply open the file (obtained from source-control and residing in the local solution/project) in VS.NET's form designer by double-clicking the file in Solution Explorer, and bam -- it has the "unsaved" asterisk and if you save it and compare to source control version you can see the modifications already made.
I couldn't find much on this. Is this a known behavior? Any idea why it does this? Kind of reminds me of the old days w/ MS FrontPage's designer view, and even the early days of ASP.NET in VS which would apply some HTML changes if you opened a WebForm in designer view, until they gave the option to disable that on a later release.
thanks for any input.
UPDATE: this appears to be continuing even with myself as the only editor of the .VB form in designer. various form elements are shifting their position very slightly. Here's a diff screenshot between my last check in and today, and I know I'm the only one editing:
...there are many like that. Always these two properties, always just a few pixels difference.
I don't have an specific answer for this, but since this drove us crazy a bit a few months ago with my team, while working on a WinForms project, I am glad to share my experience!
Every time someone opened any form on VS2015, it would ask other people who has the same solution open at that time to reload the code. We first thought the third party controls (at that time it was both DevExpress and Infragistics) we are using were re-generated on designed initialization - because they tend to do that a lot but then we realised this kept happening on forms that only contains .NET controls.
Now the funny part. This only happened to us on VS2015. We were using VS2013 before, without this annoying problem.
Long story short, then we realized the screens we are using have different DPIs, just like Cody Gray said. I am not absolutely sure if this was the reason, but since we started using TFS, obviously we don't have the problem anymore... Hope this helps somehow lol.
When I try to use a RelativePanel container within a UserControl, which is then subsequently used in another/parent page within a DataTemplate for a GridView or ListView it crashes the Visual Studio designer for that page. At run-time, it still works, but without being able to see the result within the Visual Studio designer, I am having to go back to using StackPanel controls instead, which works.
Note that I am using x:Bind within my UserConrol and that the crash in the Visual Studio designer only happens when I try to arrange the child controls with the RelativePanel using something like the RelativePanel.Below property.
The exception thrown in the designer is like:
I am using xRelatedMovieImg in the UserControl as follows:
RelativePanel.Below="xRelatedMovieImg"
So has anyone else seen this issue and if so he is there a fix or work around?
Was experiencing the same issue. Found that using Binding worked in my case. So yours might be
RelativePanel.Below="{Binding ElementName=xRelatedMovieImg}"
From what I've experienced, the Designer can be very fragile and crash for the weirdest things. Usually it helps by doing a rebuild of the project (Ctrl+Shift+B).
Also, if you're only changing the design and not debugging you can get faster launches by using "Start without debugging" (Ctrl+F5) from the Debug menu in Visual Studio. That way you don't have to wait for the debugger to get everything set up.
I am attempting to use a custom control for a live tile in my background agent. I have my live tiles successfully generating with user controls, but I now want to reference a custom control in my user control Xaml. At design time everything looks correct, no errors and I see the custom control presented in the designer, but when I run the app and the background agent runs, I receive this error:
Unknown parser error: Scanner 2147500037
The position noted in the error is the location in the Xaml where I have my custom control. If I remove the custom control the error goes away.
The custom control I am attempting to use (and its source code) can be found here:
http://blogs.u2u.net/diederik/post/2013/11/05/A-Modern-UI-radial-gauge-control-for-Windows-Phone-8-apps.aspx
I do not believe there are any references in this custom control to anything that cannot run in a background agent, so I am wondering if there is some limitation in general to using custom controls in background agents for windows phone?
If anyone has any ideas as to the cause of this error, please let me know.
I was not able to get the control to work but refactored the code to implement the straight Xaml rather than using the control. The end result is the same as what the control offered, but more complicated.
Is there a reason / fix for this weird designer issue (at least, I think it's related to the designer), whereby the controls on the form do not appear as they do in the design window when I debug the application..!
Please see the following two screenshots to demonstrate the problem (note: I have blacked out some of the content of the form, this is not the problem):
Picture 1: Showing how the form appears in the designer view
Picture 2: Showing how the form appears in debug mode
You can clearly see that some of the buttons have moved position on the form.
Note: At first glance, this may appear like a duplicate of: Windows Forms Designer destroys form layout. However, I have not installed any additional tools or components. This is simply a standard "vanilla" build of Visual Studio 2012 on Windows 7 32-bit.
I've also come across this question: UI Controls Overlapping & Fonts Issue in Windows Forms Application. However, I am not using "large fonts", nor am I using any non-standard fonts on my controls (all label and button text is left as default). Still, I can see how this would affect the control positions and will do some more checks in this area.
There's nothing happening within the form's Load method.
I'm also using TFS 2012.
What could be causing this? Is there anything I can do to fix it?
EDIT: I've removed the font property for each label and button control, allowing the system to set the default value. Still no change. Interestingly, if I open the form in design mode, then save it, then close it, then open it again, the buttons have moved... If I do this a few times, the buttons migrate until they're off the form.
OK, I've found the answer, after a bit more fiddling. It seems to be related to the Anchor property on the controls. I made a bunch of changes, testing between each change to see if there was any difference. When I selected all the controls and set the Anchor property to Top, Left, this solved the issue.
I hope this helps someone else at some point!
I'm developing a Metro-style app (for Windows 8) using C# and XAML. I have set up my viewmodels to be used as design-time datacontexts, like so:
xmlns:vm="using:hub.ViewModels"
d:DataContext="{d:DesignInstance IsDesignTimeCreatable=True, Type=vm:ViewModels
My app appears to work perfectly when run, but in the design views of both VS 2012 and Blend, I occasionally get this (unhelpful) error message:
An Exception was thrown. TargetException: Error in the application.
Stacktrace
at System.ComponentModel.PropertyChangedEventHandler.Invoke(Object sender, PropertyChangedEventArgs e)
InnerException: None
This only happens in the design view - meaning I can't set breakpoints around all my INotifyPropertyChanged() events.
What is the best approach to debugging design-time errors?
If this happens consistently or semi-consistently, you can attach the debugger to the XAML designer:
Start Visual Studio; open your project and open a XAML file, causing the XAML designer to load
Start a second instance of Visual Studio. Open your project but make sure no XAML documents are open.
Ensure that Just My Code is disabled: From the Tools menu, select Options. Select the Debugging category. In the General page, ensure the check box next to Enable Just My Code is unchecked.
From the Debug menu, select Exceptions... and check the Thrown check box next to Common Language Runtime Exceptions. This will enable first chance handling of all CLR exceptions. If you know the specific type of the exception, you can enable first chance handling for just that type.
From the Debug menu, select Attach to Process. In the Attach to: field, click Select... and check the Managed (v4.5, v4.0) entry in the list and click OK.
This is necessary because the debugger may misdetect the process as a native process if it attaches while the process is executing native code. If your project contains native code, you'll want to check the Native check box in the list as well (you can debug both managed and native code at the same time).
In the Available Processes list box, find the xdesproc.exe that corresponds to your project and click Attach.
If there are multiple processes (usually because you have multiple projects open or because the designer is reloading or has recently reloaded), it can be difficult to determine which designer process belongs to which Visual Studio instance. It's often easiest just to attach to all of them. A tool like Process Explorer can help you figure out which designer process belongs to which instance of Visual Studio.
Note: Do not attach the debugger to a designer process (xdesproc) that belongs to the same instance of Visual Studio that you are using for debugging: doing so is likely to cause Visual Studio to hang. You must always use two different instances of Visual Studio.
Do whatever you need to do to repro the bug. When it occurs, the debugger will break at the point where the exception is thrown. The debugger should load the symbols for your assemblies.
I got here while looking for info on how to debug designer time instance problems, though I did not have the same problem as rikkit. But...I'm sharing the solution to a related issue just in case others having the same problem reach here as well:
Make sure you have the "Enable/Disable Project Code" toggle set to "enabled"...in VS/Blend 2015 it's a small icon below the XAML editor
as shown here.
If it's disabled, this could be the reason your design time instance doesn't seem to be working.
Further, if it's disabled and you attempt to debug using a second VS instance, then when you attach to the XDesProc any breakpoints you set in the code-behind will report that they "will not currently be hit. [because] No symbols have been loaded for this document".
You might think that you need to somehow load the symbols, but if you open up the Modules window attempting to do so, you won't even see your module in the listing.
I lost a couple hours on this issue because of this setting being disabled. Hope this helps others not do the same.
I'm not sure about it but I believe you can check for the IsInDesignModeProperty Field. I remeber having to do so on WinForms sometimes.
Also take a look at this link Troubleshooting WPF Designer Load Failures