Question Question concerning the use of the constructor.

Saturn

New member
Joined
Jul 30, 2023
Messages
4
Programming Experience
Beginner
So I've been working with forms for a while and I've been wondering, just to be on the safe side here... is it normal to just shove everything that needs to be displayed into the constructor?? I don't use the designer. Before I would build all my controls right inside the constructor but then as form needed to get bigger and bigger so did the constructor, so I instead moved all my control codes to seperate methods and just call them from the constructor. Still basically the same thing, just neater..

Example:
C#:
public Form1()
{
    // Code for the form itself goes here, like ClientSize, etc.
    CreateMenuStrip();
    CreateComboBoxes();
    CreateSomeOtherControl();
}
 
I don't use the designer.

I also bought a Ferrari, and took the top off the engine so I could push the pistons down manually, in the right order, to move the car around ;)

I instead moved all my control codes to seperate methods and just call them from the constructor
You mean like the designer does, with InitializeComponent ? :)
 
Well, yeah that's why I don't use it, I can be much more precise.

And I haven't actually looked at the definition for InitializeComponent, but yeah I guess on the other side of that is 1000s of lines of code.

I was only wondering if what I was doing was efficient.
 
I can be much more precise.
Mostly, I'd say that's nonsense. Very few properties cannot be set on controls using the designer and must be set in code. For those that cannot, setting them after the InitComponent call is nearly always possible. I do, however, hear this "I never use a designer; i want to edit the raw nuts and bolts myself for maximum control!" often - and then the person who says that they have to have maximum control over everything has never written a line of assembler, created their own operating system, customized a graphics driver, built their own hard disk etc - they're just arbitrarily choosing which abstractions they will build on top of and which they won't

What I was doing was efficient.

It depends on your metric for efficiency. Pushing the pistons up and down in your ferrari engine is infinitely fuel-efficient; you'll use zero gas getting to the shop to buy food.. But it'll take so long to get there that you'll probably die of starvation, and as a use of time and resources that's not efficient at all. Worse if you factor in the resource cost of growing a replacement human to push the pistons
 
Last edited:
I don't use the WinForms Designer either, but that was because I had been burned too many times by the older versions of Visual Studio corrupting files and projects, and/or failing to load custom controls from the toolbar, lack of support for inheritance, and lack of support for dependency injection.

By older, I mean VS2005 through VS2012. After VS2008, I pretty just always start hand writing my WinForms UI. I gave it a try again to use the Designer in both VS2010 and VS2012, but still hit the corruption issues, or failure to load custom controls. The way to deal with the corruption issues was to aggressively use source control and check in the .SUO files and other files that aren't supposed to be checked in. Unfortunately, aggressively using source control also confuses things when it comes to loading custom controls. When I rolled back to an older version of the code, VS either would still load the newer version, or more often completely fail to load the controls.

As someone on this forum has kindly shown me, inheritance is now supported in WinForms. I don't know which version that support came in.

I hope that someone can show me that dependency injection will also work in current in versions of VS. That may make me want to try using the Designer again.

Also, if someone can show me an efficient way to use TableLayoutPanels and StackPsnels that are nested 4-8 layers deep, that may also change my mind. I used the layout panels because I like to make my forms responsive. I also lack the hand+eye coordination to precisely line up or center widgets on screen without changing my mouse speed to pathetically slow speed. In the time it takes me to eventually place control in the designer in the right place, and write the resizing/reposition code, I would have just added the controls into the appropriate panel in code in 1/10th of the time.
 
Anyway, to answer the question about adding all the controls in the constructor, that is just a side effect of the way Windows programming is typically done. In a typical Win32 program, all the controls are added in when the WM_CREATE or WM_INITDIALOG message is sent. There are some rare bits of code that dynamically add controls on the fly like some web devs manipulate the DOM as the code runs. Classic example of this are query builder UI that lets you add AND/OR clauses and groups.
 
I'd say that dynamic manipulation of the DOM is pretty much the underlying tenet of most modern single page applications!
 
(In a way, it's like the browser has become an operating system; there's this buffer somewhere that if you manipulate it with the built in programming language, then different stuff is drawn on screen - that used to be the frame buffer for the display (which still exists, of course, but further down), now it's the DOM.. We've basically just wrapped everything up in another layer of abstraction, like we always do?! - I suppose Chromebook making the browser the OS is actually kinda a logical/sensible/obvious choice)
 
Back
Top Bottom