Efficient Declaration/Creation of variables/controls - c#

I'm working on cleaning up an app I'm almost finished with and I noticed something that made me curious as to why it's being done that way. While you can edit the .Designer.cs in your project for a form, there is a lot of autogenerated stuff in there, such as the creation of variables and controls. They have the Windows Form Designer generated code which hardly ever gets touched by me. But as I was making variables in the format I like them:
string strValue1,
strValue2;
As compared to:
string strValue1;
string strValue2;
I noticed that Windows declares the controls on the bottom of the file then creates/instantiates them in the InitializeComponent() function. Now, I knowI could take the "new" instances and put them where the declarations are and it seems to run fine. My question is what's the benefit of one over the other? Or is this the way it is so Windows can autogenerate them for us? If there's a possibility of better performance for doing it one way over another, I'd like to know. Thanks guys for the help.
Example 1:
private void InitializeComponent()
{
...
this.control1 = new System.Windows.Forms.Control();
...
}
...
System.Windows.Forms.Control control1;
Example 2:
private void InitializeComponent()
{
...
}
...
System.Windows.Forms.Control control1 = new System.Windows.Forms.Control();

Do not edit that code. It is auto-generated and the designer actually reads the code back to recreate the form in the designer. When you make changes like this, it is very likely you'll bomb the designer and your form becomes un-designable. Even if you do manage to avoid crashing it, your changes will simply disappear when you alter the form in the designer.
Anything in the region that's marked "Windows Forms Designer generated code" is hands-off.
There is no benefit whatsoever to changes like these. It generates the exact same code.

You can get some more control over stuff when its done in the InitializeComponent
If you open up your .cs file (not the designer) and look at the constructor
public Form1()
{
InitializeComponent();
}
this way you can have code execute before the controls are instantiated..
if you would just create the controls when they are declared then you would not be able to do this...

Related

Why does VS2017 keep losing my derived controls?

In my app namespace = DRT, I'm creating control classes (e.g., button, textbox) that derive fron their corresponding Windows control classes, e.g.,
internal abstract class DRT_Button_Abstract : Button
{
....
}
internal class DRT_Button_CancelSearch : DRT_Button_Abstract
{
....
}
internal class DRT_Button_StartSearch : DRT_Button_Abstract
{
....
}
All together I currently have 13 derived classes that derive either from one of my abstracts or from a Windows control class. After a successful build, I see my control classes (e.g., DRT_Button_CancelSearch and DRT_Button_StartSearch) on the Toolbox and I successfully drop them onto my main form. All is fine for a while, but ultimately, I'll go to open the main form.cs [Design] (i.e., the UI designer) and it will show the error The variable '{control property name}' is either undeclared or was never assigned. for some combination of my controls.
When I examine the main form Designer.cs file, the expected code for all the controls is present EXCEPT for the expected new statement. They are not present in the main form Designer.cs file. For example, I expect to see this.drt_Button_CancelSearch = new DRT.DRT_Button_CancelSearch(); but its missing
I've tried ignoring the error, proceeding to the UI designer windows to re-apply the lost controls, but the problem just repeats with the newly applied control
What the heck is going on? Is there a way to recover from this situation?
This is most likely a problem of the Designer not being able to clear/reload its cache. There is not much you can do. In the past I:
closed and reopened all designers that have user controls
put all the controls in a separate project (in the same solution)
put all the controls in a separate solution/Visual Studio instance and set a proper reference to the controls' dll (or even nuget package)
With the first two options I have had varying success. Reopening the designer is not very convenient and doesn't work.
That last option is the best but also the most annoying because every adjustment requires a rebuild of the project and update of the reference/package.
Also make sure that all controls that you create have public default constructors and function well when this constructor is used.

Prevent Visual Studio from updating specific lines in Form.Designer.cs

I was wondering is it possible to prevent Visual Studio from updating specific lines that are changed by me?
For example i have separate resource only project (images, sounds, etc). I change some lines in Form.Designer.cs and make so all images are loaded from resource dll. But once i update Form it self everything goes back to default and all resources that were used by form gets copied to Form.resx file.
How could i solve this?
Nope.
As stated in the begining of the file, the *.Designer.* is an auto generated file. It's rebuilt every time that the file it depends upon is saved, so you should never change any code there that you don't want to be messed.
It is preferable to separate the code that the form designer generates from the code that you want to have some control over. The order in which you need to address this code can then be handled within the constructor of the form. Example:
namespace FormTest
{
public partial class Form1 : Form
{
private Label PostAddedLabel;
public Form1()
{
InitializeComponent();
PostInitializeComponents();
}
private void PostInitializeComponents()
{
if (!this.DesignMode)
{
PostAddedLabel = new Label();
PostAddedLabel.Left = 100;
PostAddedLabel.Top = 30;
PostAddedLabel.Text = "The Post-added Label";
this.Controls.Add(PostAddedLabel);
}
}
}
}
We can simply design the form within the designer, after a successful design phase we then can MOVE the declaration, assignments and related code that we want to separate to the PostInitializeComponents method.
By using the !this.DesignMode decision, the form will show the separated controls in Runtime mode. When in designer-mode these controls will not be shown, assuring that the system will not affect these controls when designing the form.
In case you want to use this methodology also in usercontrols, try to embed the "IsDesignerHosted" method over "DesignMode" from the following article: DesignMode with Controls
Hope this answers the question?
No. Visual Studio does not "update" the Designer file, it deletes it and writes an all new copy. No possible way to do what you want.
You should add your code to your code behind. It's the same class.

Winforms App Not Displaying Graphical Elements in Design Mode

I wrote a bunch of code in the .cs file in c# for a winforms application. The application runs fine, and everything is in it's place.
Something like this:
using..
namespace Temp
{
public class Temp : Form
{
Button b1;
TextBox t1;
Temp()
{
b1.Text = "Some Text";
b1.Size = new Size(50,20);
...
}
void function1()
{
// stuff
}
static void Main()
{
Application.Run(new Temp());
}
}
}
How can I modify my code (or fix it somehow) so that the design view displays the elements in their correct positions and view so that I can visually edit them instead of having to trial/error everything.
Edit for Clarification
My application runs fine. The problem is, that I didn't use designer to create the application and so in the designer view, the app is empty. But not empty when I run it, since everything is positioned programmatically in the .cs file. My question is, how can I fix this, so that the designer shows the objects correctly.
There is no quick fix other than to redesign everything?
So to get this shown within the designer you have to know how the designer works.
For every MyForm.cs there will automatically be a file called MyForm.Designer.cs be created. Within this Designer file there will be only one function called InitializeComponents(). This function will be called within the constructor of your MyForm.cs file.
The design viewer itself is responsible for the Designer file, so any change to this file while the design view is open would normally be discarded. Also if you put some code into the designer file that is not needed be the designer will be truncated.
So the next question is, when will this truncation happen? When you freshly open the design viewer of a form, it will read in everything from the Designer.cs file without making any changes. If you make any changes onto the form by the designer the complete file will be rewritten with all the settings already read in including your latest changes.
This behaviour can be monitored if you open the designer file also as source code view, make some little changes in design mode and afterwards take a close look at the left of the source file. There will be the changes marked with a yellow or a green marker.
Now after all this stuff of informations, you can try the following procedure to get your code into the designer:
Open the design view and put some simple control onto your form (e.g. TextBox)
Save and close the design view and open the Designer.cs file as source file
Copy all your variables name of your controls at the end of the file, right below the textBox1 line
Copy all your control property settings within the InitializeComponent() function right below the property settings of the TextBox
Copy all your control constructors to the top of the file, right below the constructor of the TextBox
Save the file and open your form in design view
Select the dummy TextBox on the design view and delete it
This change within the DesignView leads to a complete rewrite of the designer.cs file, ordering all your manually added stuff the right way.
So this is the way to go. Last but not least another little trick:
Every programmer uses the using-statement to not write the whole path to every class (like System.Windows.Forms.TextBox), but the designer writes always the whole path. To make it a little easier for your copy and paste session you can also add a using statement at the top of the file. After saving and changing something in Design View all this stuff will be re-written automatically. So you don't need to add all this paths manually while your adding your stuff to the Designer.cs file.
Your best option is probably to use the properties panel in the designer to set the positions etc (or maybe just drag them?).
You could go digging around in the designer file for the form (something.Designer.cs), but this isn't a fantastic idea because it can be pretty sensitive to changing things in ways the designer doesn't expect. Having said that, it looks like you're not actually using the designer to make your form (the class would be partial, for one thing), in which case you're SOL.
In that case, you need to copy the designer code from CS to designer.cs. So that you can use designer. I think this is the simplest approach.
Looks like this file was hacked from a class file instead of being generated by the system when you create a new winform.
You need at least an InitializeComponent(); call in your constructor. However you are missing a lot of other code that is generated for you when you create the file such as Dispose().
Best bet would be to right click your project in the solution explorer and click Add Windows Form then start over.

How to put an extended WinForms Control on ToolBox

I plan to add functionalities to TextBox with the following:
public class TextBoxExt : TextBox
{
protected override void OnKeyPress(KeyPressEventArgs e)
{
base.OnKeyPress(e);
}
}
The question is how can we use this TextBoxExt? Is there anyway to get this class onto the ToolBox so that we can just drag and drop it onto the form? If not, what is the best way to use the TextBoxExt?
Build you project with TextBoxExt, make sure it compiles ok.
With the form that you want TextBoxExt on, open the toolbox, right click and select "choose items"
Browse to you .exe or dll that you compiled in 1)
make sure that TextBoxExt has a tick next to it, press ok
TextBoxExt should appear in the toolbox, drag it onto your form
(There is another way of doing this, opening the designer file and renaming the instances of TextBox to TextBoxExt but manual editing of designer files can be considered hazardous by some)
I know this is super old question, but maybe still useful for someone else that has same problem like me - as it's still on the top Google :)
You might interest to use ToolboxItemAttribute (http://msdn.microsoft.com/en-us/library/system.componentmodel.toolboxitemattribute(v=vs.110).aspx).
I did this at my end to resolve the problem.
[ToolboxItem(true)]
public class PanelTitle : LabelControl {
// Whatever code to override LabelControl here...
}
Rebuild the solution and the extended control should be shown in the toolbox.
Any custom control in your project should show up in the Toolbox automatically. I have found that sometimes the controls won't show until you close a re-open Visual Studio. I assume the issue has something to do with caching of the contents of the Toolbox.
You need to add a constructor to your derived class.
public class TextBoxExt : TextBox
{
public TextBoxExt()
{
}
protected override void OnKeyPress(KeyPressEventArgs e)
{
base.OnKeyPress(e);
}
}
Your control should appear in the toolbox for your solution automatically. To have it appear for other projects, you have to do Choose Toolbox items, as others have said.
If you want to provide special design-time functionality, then you will also need to provide some additional designer related attributes and probably your own class derived from ControlDesigner.
I fell into this trap just a couple of hours ago.
I've got a .NET 2.0 Windows Application project with some custom UserControls; it worked fine.
So I decided to order my files in subfolders, to make my project a little bit cleaner.
After that, Visual Studio 2010 designer stopped loading my forms, and ToolBox won't show my controls anymore.
I freaked out, moving back source files in project root, resetting ToolBox, but nothing seemed to work.
After that, I remembered I used ReSharper "Remove Unused References", so I tried to put back unused reference, in particular System.Data: problem solved! :O
I can't say you why, but this worked for me.
Hope my experience can help someone else. :)
Bye,
Nando
I created an empty constructor for my custom implementation of UltraGridBagLayoutPanel. Although david.healed is right it isn't necessary, it is quite useful to put a breakpoint in to check that when the form initialises it is using your class to implement your custom control.
It would have been a lot easier to edit the designer file, but I tried it and changed both the field type for the control and also changed the assignment of the field to a new instance of my custom control.
private Infragistics.Win.Misc.UltraGridBagLayoutPanel ultraGridBagLayoutPanel1;
this.ultraGridBagLayoutPanel1 = new Infragistics.Win.Misc.UltraGridBagLayoutPanel();
to
private Athia.Reports.ultraGridBagLayoutPanel1 ultraGridBagLayoutPanel1;
this.ultraGridBagLayoutPanel1 = new Athia.Reports.ultraGridBagLayoutPanel1();
Doing this destroys Visual Studio every time, and to fix it requires using a text editor to put it back again. Therefore unless anyone can describe what is wrong with my implementation of this approach, perhaps calling the class the same as the control name isn't a great idea, I think the only safe and reliable way to achieve this is as Calanus describes in steps 1 to 5 or as an small deviation from that as Rob Windsor rightly points out restarting VS will bring the control into the Toolbox automatically. Unfortunately for me I then have to change all of the child controls over from the original class to my customised class :-(.
Within the same Solution this should work automatically. However, I have found that if the Target Framework aren't matching the Toolbox does not populate. ( I'm assuming really Reference needs to be of version same or lower than target of Reference. ) ( I did get a warning about non-matching Frameworks )
By making these the same Target Framework, Recompile, Restart VS. the control populated correctly. ( I also added the ToolboxItem(true) Attribute)

.NET C# - Form versus Designer code files for Event Wiring

I was just curious how others work with this kind of WinForm code in C#.
Lets say I have a Form lets call it Form1. And I have a DataGridView called dgvMain.
Where do you put the code:
this.dgvMain.CellEndEdit += new DataGridViewCellEventHandler(dgvMain_CellEndEdit);
Do you put it in the Form1 code or the Form1 designer code?
Should this "event wiring" code go in the Form1_Load method?
The reason I am ask is... if you double click the DataGridView the IDE inserts the code:
this.dgvMain.CellContentClick += new System.Windows.Forms.DataGridViewCellEventHandler(this.dgvMain_CellContentClick);
into the designer code. Should your "event wiring" code be in two places?
Short answer is yes.
Longer answer is that .designer.cs is there for code generated by the designer. if you put your own code in there, it has a chance of getting overwritten, screwing up the design time stuff in visual studio, and lowers maintainability because nobody expects custom code to be in there.
This is a touchy subject. In 1.1, there where regions for this in your forms file, but a lot of the time, the code would be over written by the designer. I'm speaking from webforms experiance, but I would only gather that it would be the same elsewhere.
Now, you actually put the eventname in the form itself (it's one of the properties on the forms designer), and the code generator will push out the += event handler thingies in the partial class. I hate it this way, but it is what it is.
I use the Designer for all event related to Component.
I use the code for all object event.

Categories