I just finished adding and removing different database models (I was trying to figure out which one I should be using for this project) then after playing around for a while I noticed one of my classes's icon changed from what is shows beside my Calculations.cs class in the first image to the Balance.cs icon.
The Balance.cs now has this Designer component so when I double click on it I see my second screen shot. This seems to be allowing me to add components from the toolbox to my class. There are actually two classes within my Balance.cs. This Designer thing is only affecting/interacting with one of them (it inherits from SerialPort).
I don't really know what changed or what I did to make this happen and ctrl+z is not being my friend here. How do I change Balance.cs back to a regular class with no designer component?
Thanks
If any of the classes in a source file inherit - either directly or indirectly - from System.ComponentModel.Component (such as SerialPort), Visual Studio will provide design-time support to you. This is sometimes unwanted behaviour, and you can safely ignore it in most cases.
If it really bothers you, you can decorate your class with the [DesignerCategory] attribute (set the category to an empty string).
Related
I have one project with my forms, etc. and one DLL-Project with UserControls and extended Controls, all with .Net4.5.1 and WinForms. A few weeks ago I did a migration from VS-Net2013 but the custom controls I'm talking about did not exist at that time. With every edit in my form inside Designer the new Form.Designer.cs is missing the instantiation of my custom gridview. All other parts regarding this control are still in the designer-code.
public class RichGridView : DataGridView { ... }
The missing part in Form.Designer.cs is:
this.dataDGV = new RichGridView(Definitions.DataType);
I can put this line back for myself into the designer-code but that's not how it should be. I was checking whether there are other files where VS might store information about the controls handled in its designer file but didn't found something. A while ago the designer has thrown away that line only a couple of times, so I could edit my form in the designer-window without problems and very seldom the instantiation was thrown away, now with every edit.
The other Project containing the DLL with my custom controls was compiled successfully and available for my Forms-Project, furthermore there was no change at all in the other project. If the point is that the custom control is outside the Forms-Project: I had to do this due to constraints in VS when dealing with UserControls regarding 32 vs 64 bit and debugging possibilities.
Not sure if there is some part of my code necessary for this question.
When I write a winforms application, I tend to create an Implementation.cs file for each form.
Say I have Form1.cs, I'd create a new file called Form1.Implementation.cs starting with partial class Form1.
Form1.cs just contains all the event callback methods (what the designer has done), everything else goes to Form1.Implementation.cs. It helps me write more readable code.
I wanted Form1.Implementation.cs to be a "subfile" just like Form1.Designer.cs is, so I edited .csproj file.
<Compile Include="Form1.Implementation.cs">
<DependentUpon>Form1.cs</DependentUpon>
</Compile>
After reload, however, Visual Studio automatically adds <SubType>Form</SubType> right after DependentUpon element. Doubleclicking Form1.Implementation.cs doesn't show code but a designer with another initial empty form.
It's like
"class Form1, which ISA Form, is(?) multiple forms."
I tried adding DesignerCategory attribute to class Form1, but it affects Form1.cs, as well.
Well, hitting 'Shift-F7' or 'Ctrl-Shift-0' is not a big deal.
I wonder if...
it's a glitch of Visual Studio,
the secondary(?) form really exists somehow,
it's going to blow up my winforms project someday
The only way of achieving what you tried is by adding <DependentUpon>, which you already know. Now Visual Studio automatically adds the <SubType>Form</SubType> for any class derived from Form. Since your Form1.cs probably contains the line public partial class Form1 : Form, this is where the SubType is coming from.
The other files - Form1.Designer.cs and Form1.Implementation.cs may contain only partial class Form1, but since partial class definitions across multiple files are still effectively one class definition, Visual Studio detects that it still inherits Form. I believe you may already know that, but just in case here's the MSDN article about the partial keyword. Don't worry about there being multiple instances of Form in this scenario. Remember this still is just one class - Form1, no mater over how many files you spread it.
In the end, all code files containing classes (even partial!) inheriting Form (or UserControl) are automatically opened in the Designer. This behaviour is by design.
The solution here is simple - either make a code file defining a separate class not based on Form, or just use F7 to view the code of that file in Solution Explorer, however annoying that may seem. It doesn't matter if that code file is <DependentUpon> anything or not. Only the inheritance of Form or UserControl matters.
The best solution though, in my opinion, would be to stick to what Visual Studio is giving you:
Designer-generated code stays in Form1.Designer.cs
Your code (what you put in Implementation), goes in Form1.cs (hit F7 to view that code instead of going to the designer)
This is an approach my team has been sticking to for a few years now. It provides a basic means of separation of Designer code and hand-coded actions. To better separate your code, use a design pattern such as MVP, as suggested by Simon Whitehead in the comments.
Right now for my User Controls I right click the control in the Solution Explorer and then choose 'View Code'. Then, in the top right corner where all the class's elements are enumerated in a dropdown box, I choose the grey'd out constructor and this brings me to the auto generated .designer.cs file that I'm looking for.
I feel like this is a really round-about way of doing it and it doesn't sit well with me. Am I supposed to be doing a better job of avoiding editing these files? Are they hard to get to on purpose or did I just clearly miss something simple in Visual Studio?
You should quite simply be able to use the treeview of the Solution Explorer to expand the user control items and see the code-behind and designer files.
This is curious, so I wonder what kind of user control (any particular project type)?
As for avoidance of editing these auto-generated files: yes, you should be weary in doing so, and avoid it wherever possible. Your changes are going to disappear if the code is ever regenerated (not that likely for user controls, I suppose), and the developers of the tool that generated it can't vouch for it working as it should if edited.
There are times when you do want to edit these kinds of files, however. So use your own judgement to evaluate the value of doing so. I find myself dipping into the DBML designer files often enough to delete the default constructor which conflicts with my own in the partial definition, haven't found another way to do what I want. Such is the situation.
Editing autogenerated code is never a good idea. The reason being that the code can be generated at any time and your changes will be lost. If you really, REALLY need to edit the code, you should be doing so using partial classes. But 95% of the time you shouldn't need to edit autogenerated code in the first place. What exactly is it that you're trying to accomplish?
An easy way to do it: Let's say you have a Label control called Label1.
If it is never actually used in your code, place some code that uses it somewhere in one of your methods:
private void Test() {
Label1.Text = null;
}
Now, put your Cursor over the Label1 control and press F12. This will take you to the definition of Label1
Hope that helps!
After several days of happily hacking away on this C# app using Visual Studio 2008, I get struck by a barrage of error dialogs showing:
Code generation for property 'valueMember' failed.
Error was: 'Object reference not set to an instance of an object.'
This happens now often when I make a tiny change in the designer, e.g. shift a control a few pixels, and then try to save. Several such error dialogs appear each second, keeping me busy cancelling all those by hammering the Enter key while trying to get alt-F4 to get VS to close.
Eventually I do get VS to close and to save the changes I made. After restarting VS, I do "clean" on the entire project, then "build" and everything works fine, the app runs fine, no problems.
Until I make another slight change in the form designer.
I don't know about any property valueMember in my app.
This makes me crazy, it is a real showstopper for my project. Any help is appreciated.
Try to Close and reopen the Visual Studio. maybe it seem silly, but it works!!
You can debug the designer using another visual studio and attach to process. If you got exception it should be easy to find it that way.
In general when openning the designer the constructor and of course initializeComponent is running.
As this is happening at design time, it is likely that you have a custom control which requires a parameter or other value which does not have a default.
When in design view in Visual Studio; a control instance is created to render it on the visual editor, but if the control requires a property to be set before it can be rendered, it will result in an error.
Can you check that all custom controls have default values, and anything referenced in the constructor that cannot have a default is wrapped by DesignMode property - see http://msdn.microsoft.com/en-us/library/system.componentmodel.component.designmode.aspx.
Similiar to #Chanipoz's answer (close/re-open) my component-rich/user-controls-everywhere forms app started to compile happily after I closed down the main form designer window.
I've had this code stack for years and have never seen the error until today. Not sure where it's coming from. But, something today about having the form open in the designer made everything unhappy. Simply closing it off of the screen made it all go smooth.
Use another instance of Visual Studio to attach to the first instance of visual studio.
Go to Debug-> Attach To Process and look for the devenv.exe process. Since you'll have two devenv.exe processes running you'll probably want to pick the one with the lower ID, that's usually the first instance of visual studio that was run.
I had to face this problem. As I have found the solution below
I am facing this issue in my customized control.
we need to implement like this
[Browsable(false)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
public MyCustomclass _Prperty { get; set; }
I had to face this problem. As I have not found the solution (much inheritance), I can tell:
.SuspendLayout() and .ResumeLayout() may be missing in code or one of them. The same is with .BeginInit() and .EndInit(). It is expected between them, that there will be = new ... and some settings for properties. Maybe someone facing this problem would find the solution with this information.
The problem is missing initialization code for a public property on the control. This will be added for you when you add the control to the designer, but if you replace a control with a derived control, or update the component, then the designer does not know how to deal with this.
If you have a control (wincontrol) with a public property PropertyA, and you add it to a form (myForm), then the designer will add all the necessary initialization for properties into myForm.Designer.cs. Something like;
Wincontrol1.PropertyA = new List<widget>();
It is not uncommon to need to modify a control slightly, lets say we have a new control MyWinControl
public partial class MyWinControl : WinControl
{
public List<wodget> PropertyDer1;
protected List<wodget> PropertyDer2;
}
If you sub this new control for the old control in myForm.Designer.cs, then you may well encounter this issue. The reason is that PropertyDer1 has no initialization in the winforms designer. PropertyDer2 won't cause any issues because it is protected. Similarly if you had a custom component and you add a new public property after the component has been added to a form.
If however, you deleted the instance of WinControl on the form, and dragged an instance of the MyWinControl onto the form instead, the proper initialization would occur and you would not see the error. The designer will have created the new control like this
Wincontrol1.PropertyA = new List<widget>();
Wincontrol1.PropertyDer1= new List<wodget>();
There are two easy solutions that do not require hiding the property from the designer.
1. If the property doesn't need to be public, give it the right modifier
2. If the property does need to be public, then just edit the code in the myForm.Designer.cs as in the code above to add the missing initializer
If could be of help I just detected a case that brings that same error message, impossible to take away :
I am developing an application in French, and I had to create a ToolStripMenuItem with an accented word in it like "annulées".
The system generated a menu item like "annuléesToolStripMenuItem" and the accent is the culprit.
Enough to delete the item, create it again in English and the just change the Text property of the menu item.
Hope it will be of some help.
One small question. I know the toolbox in Visual Studio has all the necessary components, but I was wondering if we could introduce our own "custom-made" tools. For example, the listbox tool. I've created a "SpeechListBox" class in which I've mentioned all the methods that I want my listbox to use, but when I'm in the "SpeechListBoxApplication" class (where I wanna use this listbox), the listbox with my methods doesn't show up, instead the general listbox tool that doesn't have my methods shows up.
What I want is to write something like private speechListBox1 SpeechListBox; and somehow introduce a visual form to the design class without confusing it with the toolbox's listbox. Making the program realize that I want this type of list box with all the extended methods, not the general toolbox type.
Is there any way to either make our own listbox or add methods to the original listbox tool?
Well, if you derive your SpeechListBox from a class that either is or derives from System.Windows.Forms.Control, when you compile your project it will show up in the Visual Studio control toolbox.
If you aren't sure which class to derive from, you'll have to make some decisions. If you want to hand-draw everything yourself, derive straight from Control itself. If you want to build a control is is a composite of other controls, consider deriving from UserControl. You don't explicitly list exactly what you're trying to do with your SpeechListBox, but you may want to consider just using a ListBox but supplying it with custom drawn list items. You could do this by making your class derive from ListBox or just configuring a ListBox to do what you want right in the form on which the listbox resides.
Is your code in separate project? Then you have to add that project to your SpeechListBoxApplication project's references in the solution explorer.
Otherwise your inherited control (public class SpeechListBox : ListBox) should show up, when in the GUI Designer in the toolbox in either the Common section or a section labeled after the project.