0

I understand what the InitializeComponent() does in the background - it creates the form and all the controls that were added in the designer. However, what I have not found is WHEN you would add a Public Sub New() constructor to a form and what you would add to that versus the Load() sub.

I did find that this is a good place to put my BackColor and BackGroundColor settings since they are user-preference and stored in Settings. What else should I put in there? I have always used the Load() sub to do any work with controls. Examples: Adding handlers, loading comboboxes, setting DGV columns, loading DataTables) Should I be doing that in the New constructor? Does it make any difference?

ekolis
  • 6,270
  • 12
  • 50
  • 101
Cory
  • 65
  • 7
  • 3
    https://stackoverflow.com/questions/2521322/what-setup-code-should-go-in-form-constructors-versus-form-load-event – Hans Passant Sep 18 '19 at 15:12

3 Answers3

1

The Load event is fired just before the form is displayed for the first time.

... but that might not be right away. It's possible — common, even, in certain environments — to create a form and have it available to code long before the form is ever shown on screen. The form might even never be shown on screen.

Take, for example, a settings form, where properties are defined in the class that map to user preference fields on the form. Someone might decide to build an application that looks directly at a known form object instance to read preferences, but if the user never goes to change anything that form might never display to the screen, and the Load event would never fire. That's just one example, and whether or not it's a good idea is another story; it's enough to know I've seen it happen in real code.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
  • I had never thought about having a form "loaded" but not VISIBLE before. That is an interesting concept. I'm pondering whether that would be a good idea to do with numerous forms in an app. Say I have a main form, and then 8 possible forms that all have some controls that need to be populated. Would it be efficient to "load" all of those forms at run-time and then just SHOW the form when it's called? – Cory Sep 18 '19 at 19:13
0

However, what I have not found is WHEN you would add a Public Sub New() constructor to a form and what you would add to that versus the Load() sub.

Here is an example to answer (the core?) question of yours. Suppose you have a Form to edit a product. Let's call it ProductEditForm. Your use case for this Form is to edit the values of an existing Product in your system. How would you tell this form what product to edit? By requiring the passing of a Product object when you instantiate the form. For example, in the code page of ProductEditForm:

Private _product As Product = Nothing

Public Sub New(ByVal p As Product)

    ' This call is required by the Windows Form Designer.
    InitializeComponent()

    ' Add any initialization after the InitializeComponent() call.
    _product = p
    ' Now, you can reference the values of passed-in product "p" via variable _product, anywhere in this Form.

End Sub

And you would instantiate ProductEditForm like this:

Dim p As New Product
p.ID = 1234
p.Name = "Widget"
p.Cost = "10.00"
p.SalePrice = "30.00"

Dim f As New ProductEditForm(p)

In this example, you are making good use of code in Sub New(). You could also, perhaps, assign the values to _product to TextBox controls, check values in _product to set colors or fonts, etc.

(Side note: this method of requiring a target object in the constructor completely avoids the way-too-common bad habit of some WinForms programmers to pass data between Forms via public form properties or global variables.)

HardCode
  • 6,497
  • 4
  • 31
  • 54
  • I happen to be one of those programmers that is passing variables between forms in a not-so-good fashion. Obviously because I had not known how to properly use the New() function. I will be going through this application and updating that as necessary now! – Cory Sep 18 '19 at 19:10
  • And it's not just limited to Forms. You can use objects (like `Product` in the example above) and pass it to other tiers of your application (business layer, data access layer, etc.). It's easier to read and follow code when data is wrapped in objects. – HardCode Sep 19 '19 at 14:01
-1

If you're talking about Windows Forms, I've found that it's best to do your UI setup in Load rather than in the constructor (New), because sometimes if you do it in New then certain things won't be initialized yet and you'll run into null reference exceptions.

ekolis
  • 6,270
  • 12
  • 50
  • 101
  • 3
    Visual studio almost eliminates any risk if you pay attention: `Public Sub New()` `' This call is required by the designer.` `InitializeComponent()` **`' Add any initialization after the InitializeComponent() call.`** – djv Sep 18 '19 at 15:24