views:

38

answers:

2

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();
A: 

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...

Petoj
So, I guess to go further on this, would you say that the processing within my app will run faster before the components are intialized? EDIT: And yeah, I know it's in the constructor, I just wanted to know some of the meat of it so I knew if I'm using it to it's full capability or if I should try some new stuff.
XstreamINsanity
well if it will run faster or not is a complicated manner :P, but even if there is a difference you wont notice it..
Petoj
lol. And that was my main question/concern. I've only been in the field for 3 years, so I can build an app. But building the most efficient app, I'm not there yet. I didn't know if it would cause memory leaks or something like that, so I wanted to make sure.
XstreamINsanity
+1  A: 

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.

Hans Passant
Yeah, I just noticed that it de-tabbed my arrays like I had them. :( That kind of makes me bring up another question. If it's autogenerated and will converted back, why is it available for us to look at? Couldn't they wrap that somewhere so we don't touch it? You know us programmers, we like to tinker with things. :)
XstreamINsanity
They did, that's what the #region is there for. It is collapsed by default. Making code visible to the compiler but not a text editor is otherwise a non-existing trick. And looking at it is quite legitimate.
Hans Passant
:) I meant a way that we quite literally couldn't look at it. A way to make it to where the ONLY way we could change anything is through a form or something. I don't want it that way, I'd rather be able to edit it, but man, I'd hate to be someone who doesn't know this and edit a huge Form just to have a lot of what they did undone. Thanks for the info.
XstreamINsanity