I have created a class that is simply THIS
Class UserControlBase
Inherits UserControl
End Class
Then I changed the Inherits clause in each of my UserControls designer file to
Inherits UserControlBase
I know that generally you shouldn't manually mod the designer file. But in cases like this what else can you do? Is this OK? Is there a best practice I don't know about? Is there some other way to accomplish the same end (extending UserControl) ?
I have not had issue changing the Inherits line, adding Namespacing, or adding Imports/Using statements. If you need to do any of these 3, you won't find many other ways to handle these requirements.
I change them all the time in my C# projects... often it's the easiest way to duplicate something that you've done once in the designer to a similar form and you want to do the same thing in a different form. Visual Studio is perfectly capable of reading in your changes and incorporating it into the designer. I really don't know why there is a comment saying not to edit it. My advice would be just make sure you use source control, go ahead and edit it, test it well, and if it works, great, if not you can always back out your edits.
No. It's never a good idea to modify a file that's generated.
The Designer files are pretty simple code; the only thing that you'll typically find in there to complicate matters (but only slightly) is BeginInit/EndInit calls at the top and bottom of the file--between those the code is pretty forgiving.
*That said, do not put any code in there that will only execute at Runtime. Any runtime-dependant code will fail at design-time, so trying to open your control in Design view will blow chunks. It used to give you the Red Screen of Darn, but I'm not sure what effect the IDE has notwadays--but if things blow up and the usual tricks fail to remedy them then try removing your customized sections.
Further on that note (not to scare you, but rather to hopefully head off some of the difficulties we had) the means of determining if your code is executing in Runtime or Designtime often fail if your code is not part of the currently built solution/project.
So to bring it all home, simple UI layout/winforms modifications are perfectly fine to do by hand in the designer code. Databinding and external dependencies (with the exception of calling third party control libraries) should be cautiously approached.
Related
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 working on a large WPF project using MVVM. We're currently still deciding the extent to which we'll use code-behind, but so far we've gotten along fine with none at all (except for InitializeComponent on windows). However, I recently started using typed DataTemplates to apply views to my view models, and it seems these views, like windows, do not work without the InitializeComponent call, when, according to this article, I thought they would. The DataTemplate just declares a view. When I delete the view's code-behind file, the view model renders completely blank. When I leave it in, it's fine. Any ideas why I might be seeing this behavior?
First, you may be overlooking something important: I used that article heavily when learning MVVM/WPF as well, and I never thought it suggested eliminating InitializeComponent calls from the View.cs.
In fact, doing a quick search reveals the following (under Relaying Command Logic) [emphasis mine]:
Every view in the app has an empty
codebehind file, except for the
standard boilerplate code that calls
InitializeComponent in the class's
constructor.
I've been applying the same pattern you describe while leaving the default code-behind for each view in place, and so far it's smooth sailing. :)
Further: If you check out the definition for the default InitializeComponent(), you'll see that the generated code contains the following statement:
System.Windows.Application.LoadComponent(this, resourceLocater);
I haven't tested to make sure this is the case, but I'll wager a fiddle of gold against your soul that preventing that line from executing is going to affect the rendering of your view... ;)
According to djacobson, even the solution by Josh Smith that I referenced in my question cannot render its views without the code-behind, so the line stating this can be done is misleading. It seems the only way to avoid code-behind for your views is by not putting them into UserControls at all, but just keeping the XAML directly within a < DataTemplate > tag.
Okay,...I've recently inherited a downright shocking Silverlight 4 application and the Xaml is worse than you could possibly imagine. I'm going through a clean up operation and I'm looking to save time if I can.
One of my problems is that I've got a bajillion Button controls; some have a Style set and some don't. I need a quick and easy way (if one exists) to remove all of the Style attributes from any Button (or whatever) that has one set. Is this possible?
I have access to VS2010, KaXaml, XamlPad and Blend 4.
Thanks in advance..
Forgot about this question so in response to Robert Claypool's question,...No, not really.
What I actually did was remove all the styles and go through the big daunting errors list one by one. I tried a little find and replace magic first but that failed miserably no matter how clever my Regex got.
No choice here but to just hand-ball it I'm afraid.
Suppose I have a base form Main1 which may need to be altered slightly, including perhaps adding additional Controls and altering the size/location of existing Controls. Those base Controls which I need to alter I set to 'protected' in the designer. So I have another form, Main2, that derives from Main1. Then I have another form, Main3, which has even more additions/alterations but needs the additions of the 2nd form. And so forth. My inheritance chain looks like:
MainX : Main(X - 1) : ... : Main2 : Main1
This works great and allows me to have designer support when moving around and resizing Controls, but I am always wary of inheritance in general and especially when I have a chain this big.
Am I going to pay for this later?
Inheritance is your friend.
Another approach would be to use nested master pages, which may make more sense depending on your application. I'd avoid creating new classes just to change control size or other markup-related content.
I've done this a lot in the past (admittedly not much past 3 or so levels deep) and it's worked pretty well. From time to time the controls seemed to disappear in my "inheriting" form (normally at creation time), but that was back in VS2002/2003 and .net 1.0/1.1. As long as I could call up the finished form successfully (i.e. all controls present and correct) everything was OK.
Currently in my XAML editor view I am experiencing frequent seizing episodes of around 3 seconds each. I've been able to narrow down the reason for it to custom namespaces.
By default, my page has the 2 default XMLNS declarations:
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
</Page>
This works fine, no seizing. However as soon as I add an XMLNS for controls inside my application it starts seizing up.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:controls="clr-namespace:MyNamespace.Controls">
</Page>
Its not specific to just that namespace. I've tried a large variety of namespace combinations. Basically any XMLNS pointing to one of MY namespaces causes this issue.
I'm not really sure how to diagnose this issue. Any pointers?
SOLUTION
We found out the solution. We had a reference to a Microsoft assembly that was about 7mb in size (ACtiveX stuff for web browsers). When removed, everything sped up. We're now looking at ways to abstract that assembly so that it can exist in the runtime folder but no need for a reference to it from the project. Thanks all for your ideas.
First of all we should find out what happens when you close quote mark inside Visual Studio. It's just a program (although a good one) - debug it/profile it.
Do you have any additional plug-ins
installed? Turn them off.
Turn off Intellisense.
What happens with MS Expression Blend? Does it seize?
Turn off all antiviruses.
Run Process Monitor and track what happens with VS. Are there any errors with file name/registry keys resolution?
If nothing helped, use profiler on Visual Studio process.
If nothing helped, write your question on StackOverflow. Oh. Hold on. You did this already. Let's wait for more responses :)!
Cheers!
This could be that it is looking for something or that it is recompiling code.
Select the output tag to view compile activity, then see if that is what it is doing next time it siezes up.
In some projects we get this behaviour if we exit debug mode by pressing the stop debug button instead of exiting the program.
Also, there have been several bugs reported for Visual Studio hanging when using DataGrid controls with WPF, it could be related to this. Here are a couple:
http://wpf.codeplex.com/WorkItem/View.aspx?WorkItemId=10542
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=420621
Are you running a real-time virus scanner? These can often cause sluggish performance when VS needs to compile your code...
A plausible guess is that this behavior is tied to VS's XAML editor attempt to provide Intellisense for nodes declared with clr-namespace. This is after all one of the differences between clr-namespaces and other types of namespace (whereby the URI is merely taken as a unique string, but no attempt is done to assert the definition of the underlying XML language.)
A possible workaround is too define the xmlns prefix under a bogus URI, during the xaml editing phase (and hence forgo any hints from intellisense), and to revert to the proper clr-namespace for other phases of the project.
Also, maybe adding the assembly=xxxx to the namespace declaration may help the situation. Even if the assembly in question is that of the current application, this may save the editor and associated intellisense some hesitation.
Another, counter intuitive workaround could be to have these controls in a separate assembly, as this may spare the system from the Intellisense's attempts at dynamically inferring the types structure from the source code, with all the associated hickups caused for example by the background polling for changes etc. (I do not know that it tries to do that, but sometimes, tools are getting to be quite intelligent, but too result in CPU or I/O blocks of the kind you describe.