It happened again. My test data is not shown any more. I see only class and property names. Restarting does not help this time. Retracing neither.
I've been rewriting my whole project since that happened.
Now I tried to use Test Data class to address it from custom user controls so it would look like:
...d:DataContext="{Binding Source={DynamicResource TestData}, Path=Emploee}"...
//in resources
<main:TestData x:Key="TestData"/>
Not like it was previously:
...d:DataContext="{DynamicResource TestEmploee}"...
//in resources:
<shar:PVEmploee x:Key="TestEmploee" Name="Alpha" Surname="Omega" Phone="77777777" PVProfession="{DynamicResource TestProfession}"/>
<shar:PVProfession x:Key="TestProfession" Name="Some obnoxeously long profession name"/>
And right after those changes in this control (I've done it previously few times already to other controls, I've copied from previous project version) the designer crashed. Now I see
this ridiculousness, instead of test data
I am frustrated. Am I supposed to restart it again? Or there could be some way to fix it.
Answer to almost not realated question Actually worked well (the question was - how to crash a Designer =D ). If I kill designer in Task Manager, and click 2nd option in Studio. The Designer loads pretty well in a right way. All my Test Data right there. Or I found later that I can click small document icon on designer bottom to reload it with or without user code.
After a few such resets it started behaving. Marvelous!
Related
I have built a class library that acts as a GUI framework that can be inherited by other projects. This application is based on projects Wild and Gemini.
My problem is that upon restoring Avalon Dock's layout using the standard serializer
var layoutSerializer = new XmlLayoutSerializer(manager);
where manager is type DockingManager. The manager restores and empty tab. My guess is that Caliburn Micro cannot find the stored ViewModel (named HomeViewModel). However, I am struggling to confirm this.
I believe my bootstrapper to be correct and that the MEF containers are being setup correctly to allow resolution of external types. I have debugged the project to a point where I think this issue is occurring and in the output window I can see Attach(Home) where the attach is occurring (note, "Home" is the display name of the HomeViewModel). However, I don't know what is wrong with the attach process as this is handled by MEF/Caliburn.
I am really stuck with debugging this an wondered if
Any one could offer any insightful advice as to how to proceed with the debugging process?
Anyone would be willing to take a look at the solution?
I have spent a hell of a lot of time debugging this without any luck and the problem is sufficiently esoteric and illusive as to render most posts here irrelevant to me.
Thanks for your time.
as discussed and after looking on the sample code provided, I understand that the following
HomeViewModel or can say LayoutItemBase is not supposed to be reopened as ShouldReopenOnStartup is set to false
if you close the application while leaving a document open for HomeViewModel it is restored on next start with blank view [Not OK]
Analysis
the SaveState method was correctly honoring ShouldReopenOnStartup value and was not emitting the state for the HomeViewModel but dock manager was still emitting an element for the document.
So upon next restart the LoadState does not find any stored state but a window was created as an element was present in the dock manager's layout state
<LayoutDocument Title="HomePP" IsSelected="True" IsLastFocusedDocument="True" ContentId="d716f824-cfff-4b54-8fd6-2d026a99369a" .../>
you did try to use e.Cancel property of Serialization callback to cancel the event, but seems like it is not supposed to prevent of loading a window but just simply to cancel the event if not needed.
Resolution
So the ideal approach is to close the documents which are not supposed to be restored before saving the layout
here is how I did
ShellViewmodel.cs : Line 279 method SaveState(string)
change the following code
if (!item.ShouldReopenOnStartup)
continue;
to
if (!item.ShouldReopenOnStartup)
{
//this item is not supposed to be restored so close the window before saving layout
IDocument doc = item as IDocument;
if (doc != null)
CloseDocument(doc);
continue;
}
When I add my user control to the code in a XAML page the typeahead which prompt for elements and attributes stops working in that page. Everything works fine in runtime and I can display and use the user control as I want to, but in design time something gets corrupted.
If I comment out the user control using <!-- --> type-ahead starts working again. So while editing the XML I keep it commented, but it is a bit inconvenient to comment/uncomment every time I want to edit and then build & run.
The local namespace defined is shared among all classes in the project.
<local:MySettings Visibility="Collapsed" x:Name="MySettings" />
This often means your control is doing something that upsets the designer. Check the output tab/window to see if there is any output?
All of a sudden I notice that typeahead is working again...
As far as I know I did two things:
I did a Rebuild (instead of Build) in order to see if there were any warning messages
I closed VS to work on other things, and reopened just now.
Don't know which one of these was the cure for the problem, but at least it disappeared!
I'm encountering a problem with the WinForm designer. I made a new UserControl, I added a DataGridView, some other elements and a TreeView. With the gui I named all those new components. Now it's time to code that stuff and I realise that the designer missnamed my node of my TreeView. The Designer also added new columns from my DataSource even if it was set to AutoGenerateColumn to false. I though: "Well time to clean some Designer crap again..." and I cleaned that stuff up in the InitializeComponent function (I know it's labeled "Do not modify with the code editor" but... do I have the choise?
Anyway, my problem is : When I go back on the Design view, the VS Designer seems to regenerate the code back but not even how it was. Now the designer declares my DataGridView and my TreeView as local members of InitializeComponent function. I can easily repair and undo my changes but I would like to understand and know if there is a way to disable the auto code generation of the designer.
Also, I tried to make another function which have all what I need so the designer don't screw it up and call it into the initialize component. This solution works at run time but not on Design view. I'm kinda low.
As far as I know, the short answer is no. If something is marked as Do not edit due to code generation., then do not edit it :). I would suggest reading up on partial classes, as that is how you can modify classes without actually messing with the auto generated code. In your case, you will need to go into the designer and fix everything there so that the auto generation works as you expect it to.
I'm using Visual Studio 2010 to create a small WPF application. I've created a user control that I am now trying to add to my main form. The user control does show up in toolbox but every time I try to drag the control to the form I get the error:
The enumerator is not valid because the collection changed.
I should know what's wrong and it is bugging me that I can't figure it out.
You have a bug in the constructor of the usercontrol - you are using a foreach-loop over an IEnumerable and while the loop is running, the IEnumerable is changed, this is not allowed with a foreach loop. Use a for loop instead if you are manipulating the Collection you are iterating over.
The problem here is that you don't know what code is throwing the exception.
WPF is terrible about exceptions, especially in constructors. The framework insists on catching and re-throwing a new exception, usually multiple times, and it's difficult to find the original stack trace. I've found the easiest way to track down this kind of error is to tell Visual Studio to stop as soon as the exception is thrown, rather than waiting until WPF has re-thrown it a couple of times and made the details difficult to dig out.
I don't have Visual Studio 2010 in front of me, but here's how to do this in VS2008 -- 2010 is probably similar:
Go to the Debug menu > Exceptions...
Next to "Common Runtime Language Exceptions", check the box in the "Thrown" column
Then debug your app again. It will stop at the line that's actually causing the problem, and it'll be much easier for you to see what's going on. And if you're still not sure why it's throwing an exception, you'll be able to post a code sample.
In order for a user control to function properly you need to have a constructor that takes zero arguments. This way the form designer has a way to render the control in a "default" manner.
I then overloaded my constructor to take the arguments I needed to actually run the control properly and everything worked as expected.
You need to:
Remove the DLL reference
Add a reference to your control
Rebuild the solution
Add your control. It should work!
I have found the following in WPF:
I have a form with AllowTransparency=true. Inside the form I put a Combobox.
I add some items to the combobox.
I run this application and click on the combobox. At first it does not seem to appear at all. On closer inspection (after adding more items) I see that it is actually appearing behind the form. If I add enough items it become visible from behind the form.
If I just change AllowTransparency=false, then all is fine.
This looks like a bug in WPF (3.5 SP1).
Any one know of a workaround for this?
Go to
https://connect.microsoft.com/dashboard/?wa=wsignin1.0
submit your feedback after searching #
https://connect.microsoft.com/VisualStudio
https://connect.microsoft.com/VisualStudio/feedback/CreateFeedbackForm.aspx?FeedbackFormConfigurationID=1160&FeedbackType=1
and mention steps to reproduce.
There was an update of 3.5sp1 but you could test,but I doubt
http://www.microsoft.com/downloads/details.aspx?familyid=6c095bba-6100-4ec9-9c54-6450b0212565&displaylang=en
AllowTransparency is slow and buggy and shouldn't be used - it's a great way to run into bug in various display drivers.
You can get almost anything you like without using AllowTrasparency, take a look at this post for examples:
http://blogs.msdn.com/wpfsdk/archive/2008/09/08/custom-window-chrome-in-wpf.aspx