[RESOLVED] Form is partially executed before Form_Load Event

[mible]

Hi,

I have a problem concerning the Form_Loading event:
When I want to load a new Form (ImageDisplay) the ImageDisplay_Load Event is not executed first.

Instead it runs through the global variables definitions and then executes a Private Sub called numericupdown1_changed.

The numericupdown1 field is part of the form I want to load and has not been touched.

That is my calling sequence:

Private Sub Dispalydata_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Dispalydata.Click

        Dim myDisplay As New ImageDisplay

        If myDisplay.Created = False Then
            ImageDisplay.Show()
        Else
            ImageDisplay.BringToFront()
        End If
    End Sub

This is the form which should get loaded:

Public Class ImageDisplay

    Dim lambda As Integer = 350
    Dim DataTags As Boolean = True
    Dim DataPoints As Double(,)
    Private m_BufferBitmap As Bitmap
    Private m_BufferGraphics As Graphics
    Public x_samplesize As Integer = Main.NumericUpDown1X.Value
    Public y_samplesize As Integer = Main.NumericUpDown1y.Value
    Public currentxpos As Integer = 0
    Public currentypos As Integer = 0


Private Sub ImageDisplay_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        ....
'Initialize

    End Sub

The strange thing is that for other forms in my code it works well and starts with the form_load function.

Any guesses where to look at to get rid of this error?

Thanks in advance

[NickThissen]

I would think that is due to the fact you are using those NumericUpDown controls as the default values for two integers. Simply don't give them any value yet in their declaration, but give them their value in the Form_Load event.

[stanav]

Yep, just declare the x_samplesize and y_samplesize variables but don't initialize them yet. And then in form load event, you initialize them. Also, you're not setting the value of the numericupdown controls in form load event, are you?

[mible]

Thanks a lot for your fast answers.

I did what you said and assigned values only during the form_load event.

Now it executes the following sub directly before the form_load event:

Private Sub NumericUpDown1_ValueChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles NumericUpDown1.ValueChanged
        lambda = NumericUpDown1.Value
        drawGraph(ReadtoDataArray(lambda), picGraph)
    End Sub

No, I don't set the values of the NumericUpDown1 control during _load.

Any further suggestions?

[stateofidleness]

you could put a boolean variable. Globally set to false. in the form load event set it to True.

in the ValueChanged event, test if the boolean value is true (this means the form was loaded) then execute the code you have above, else exit sub

[kleinma]

I would think that is due to the fact you are using those NumericUpDown controls as the default values for two integers. Simply don't give them any value yet in their declaration, but give them their value in the Form_Load event.

This doesn't add up to me, because the best I can tell from the code, the NumericUpDown controls he is using to assign those variable values is not from the form that is loading, but from a different form called 'main'

Calling a 'get' on a property should not be a reason for it to fire a changed event. Only setting a value should do that.

I think the more likely scenario here, is that the numericupdown controls on the form that is loading (ImageDisplay) he set some default value to them at design time.

If you set the value of a NumericUpDown to anything but its default of 0 at design time, then the IDE generates the code to assign this value when the form is created. It is in the hidden partial class, and would look like

Me.NumericUpDown1.Value = 10

Since this code fires when the form is created, it invokes the ValueChanged event.

So maybe the OP can say if this is the case or not...

[techgnome]

What you are seeing is the InitializeComponents sub running during the constructor call... which happens when you first instantiate the form, but before it is loaded.... So how do you get around it? Easy, remove the Handles after the event handler... then use AddHandler in the load event to re-hook it back up. I've used this technique to avoid databinding problems when my datatable hasn't been loaded yet.

-tg

[mible]

kleinma is absolutely right. When changing the default value during design time(!) of the numericupdown1 control the constructor initializes it with the first "mentioning" in the code.
The workaround is exactly like techgnome posted: Removing the Handler of the sub in the code and put the following line in the load event.

AddHandler NumericUpDown1.ValueChanged, AddressOf NumericUpDown1_ValueChanged

Consequently VB changes the default values with the constructor before the Handler is attached to the sub!

Thank you very much for your fast help!!

[NickThissen]

I stand corrected kleinma, that didn't really make sense after all lol.

And to mible & techgnome, why not simply not set the value at design-time, but just set it during form_load? Seems a lot less complex than using Remove/AddHandler. Maybe with a database I can imagine, but with a numericupdown control there should not be any trouble.

[kleinma]

I think the issue is he wants to prevent the ValueChanged event from firing when setting an initial value. Even setting a default value in Form_Load would cause the ValueChanged event to fire when he doesn't want it.

Without waiting to add the event handler until after the initial value is set, I think the only other viable solution is the boolean flag to indicate loading status in the ValueChanged event and bypass it.

[mible]

Yes,

that was what I wanted to prevent. Because the Numeric upDown Sub will execute a function which first needs a file to read. And I want to give the user the possibility to load his own file AFTER the new form has completely loaded. (Otherwise an exception is thrown)

After the file is specified the user can define with the numericupdown what part he is particularly interested (i.e. the wavelength between 350 and 2500 nm in my case) with automatic execution of the function.

I think the compiler should built in the new design-time default value when building the code, rather then when executing it. Maybe a possible improvement for future generations of VB.