• Status: Solved
  • Priority: Low
  • Security: Public
  • Views: 92
  • Last Modified:

Windows Form Load event is not triggered.

I have an old mostly VB based  Windows application I have been trying to move from 32 bit systems (W2K & XP) to 64 bit systems (W7 & W10).  I am using VS2015 for this work and have the configuration set to "Any CPU".

The main form of this application inherits directly from System.Windows.Forms.Form.   When I start the application the main form's Load event handler is not called.  Other form events (e.g. Activate, Resize) are called, but as these rely on objects defined during the load event they raise appropriate null value exceptions.

I have set breakpoints in the Load event handler to confirm that it really is not being invoked.

My searches have so far yielded only results that pertain to conflicts with missing data bindings.  There are no data bindings used within this application.

Any ideas about what might cause this lack of a load event trigger will be greatly appreciated, as will suggestions about how I might further diagnose this problem.

  • 5
  • 2
2 Solutions
Can you search for += to find all event hooks
omegaomegaDeveloperAuthor Commented:
Hi, p_davis,

I'm not sure I understand the question (or I'm sure I don't know how "+=" might relate to event hooks.)  In any case however, the "+=" construct does not occur anywhere in the code for the solution.

Can you please explain further.

Éric MoreauSenior .Net ConsultantCommented:
can you show your event's code? Do you have the "Handles Load" to the right of your event? You should see something like this:
Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.Load

Open in new window

Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

omegaomegaDeveloperAuthor Commented:
Hello, Éric,

Thanks for your note.  Yes, the "Handles Load" is there.  Missing that would certainly make it appear that the event wasn't being triggered, however this code was working fine under VS2005 on W2K and XP systems.    The full code of the event handler is below.
    Private Sub frdSupSim_Load(ByVal sender As Object, ByVal e As System.EventArgs) _
                                                                Handles MyBase.Load
        Thread.CurrentThread.Name = "SupSim Primary"

        ' If End User Licence Agreement acceptance is required, show the splash 
        ' screen and get the user's acceptance or rejection of the agreement.
        Dim frmSplash As frdSplash = Nothing
            mdptSplashLocation = Point.Empty
            If (EULA_AcceptanceRequired()) Then
                frmSplash = New frdSplash(frdSplash.aenmSplashMode.Agreement)
                ' The EULA acceptance form will be centered on the application window. 
                ' (Because the application window is not yet in its specified location, 
                ' a reference rectangle is used for centering the EULA acceptance form.)
                Dim dreApplication As Rectangle = FormPosition(Me)
                frmSplash.StartPosition = FormStartPosition.Manual
                frmSplash.Left = dreApplication.Left + CInt((dreApplication.Width - frmSplash.Width) / 2)
                frmSplash.Top = dreApplication.Top + CInt((dreApplication.Height - frmSplash.Height) / 2)
                mdptSplashLocation = frmSplash.Location
                frmSplash.ApplicationTitle = gkstMsgAppTitle
                abooAborting = (frmSplash.EULA_Accepted <> aenmTripleState.Yes) ' If the user doesn't agree, 
            End If                                                              ' abort the startup.
        Catch ex As Exception
            abooAborting = True     ' An error during user acceptance will also abort the startup.
            ReportError(ex)         ' Report unexpected errors.                 
            If (frmSplash IsNot Nothing) Then
            End If
            If (abooAborting) Then
                ' The user rejected the EULA (or an error occurred).
            End If
        End Try
        If (abooAborting) Then Exit Sub

        ' Define this as the main form so that it is easily available globally.
        gfrmMain = Me           ' GUI specific reference (type = frdSupSim).
        afrmMaster = Me         ' General reference (type = Form).

        aicnDefault = Me.Icon   ' Set the default icon for this application.
        afrmDebug = Me          '~TBR (For debugging purposes only.)
        UpdateStatusBar()       ' Clear design text from status bar.

        ' Define standard object types for global reference:
        gtypUnitControlDef = GetType(clsUnitControlDef)

        ' Set form/window geometry.

    End Sub

Open in new window

I think there is nothing very unusual in there.  The object gfrmMain is referenced in subsequent events (Activated and Resize) and being Null of course causes subsequent problems there.

Thanks and best regards,
omegaomegaDeveloperAuthor Commented:
At a loss to explain the lack of trigger for the Load event I undertook a few experiments.  To begin, I added a new form to the project.  This was a very simple form with only one Label field and one String variable initialized to "Original".  I added a Load event handler that changed the value of this string variable to "Load event called" and an Activated event handler in which the Label's Text property was set to the value of the string variable.  I then changed the projects Startup form to this new form.

Everything behaved as it should, with the Load event being triggered as would be expected.

I then began an iterative process of copying the properties, controls, components etc. from the problematic form to this new form, expecting at some point the new form would exhibit the same problem as the old.  I hoped this would provide a clue as to what was causing the problem.  In fact, I managed to copy the entirety of the old form to the new without any problems arising.

So I am still at a loss to explain why the Load event was not being triggered in the problem form.  However I made the following observations:

  • In the original form, the entire definition is contained within a single form/class with the designer code embedded in a (hidden) region, as was normal for the earlier versions of VS.  The designer in VS2015 seems to be able to handle this old method without any issues.  However when creating a new form the designer code is implemented in a partial class (and separate file) from the developer's code.
  • In the original form, five declarations originally within the designer region had somehow migrated to be in front of this region.  This was clearly an inadvertent change, as the lines appeared in the middle of a comment section, disrupting it's flow.  Reviewing the source control for this module I discovered that this change had not happened as a single event, but happened progressively (e.g. one declaration at a time) over several check-ins of the code.  Since the comments associated with the check-ins did not mention this change, I am confident it had been unintended by the developer and suspect a bug in the early designer code.  (As an aside, all of the misplaced control declarations were menu controls.)
  • While the VS designer (perhaps surprisingly) did not have any problem with the misplaced control declarations, I suspected that they may have somehow been responsible for the missing Load event.  To test this, I replaced the new form in the project with the original problematic form.  My intention was to return these misplaced declarations to their rightful location and see if the Load event would then be triggered.  However before making any changes to the form, I once again ran the project and this time found no problem with the triggering of the Load event.  It seems that simply removing the form from the project and then reinstating it may have been sufficient to eliminate the problem.

So, while I am now able to proceed with my work, I am still at a loss to understand why this problem arose.  And as with any problem that vanishes without anything apparent having been done to fix it, I am left feeling a little nervous about the possibility it will reappear at some most inopportune time.

Thanks to all who have given some consideration to my problem.  I would still be very pleased to hear any insight about what the actual solution may have been.

Best regards,
Éric MoreauSenior .Net ConsultantCommented:
I never seen that before. I would need to experiment it to be able to see what is going on.
omegaomegaDeveloperAuthor Commented:
Nor have I.  It does seem bizarre.  

Some experimentation would be good to try to understand what happened, however I'm not even sure I could now recreate the condition.  This would require going to the most recent backup and trying to replicate the changes I may have made since then.  Sadly, I haven't the opportunity (i.e. time) at the moment for such experimentation.  Were I to encounter the problem again I would image the disks involved so I could easily return to the known (problematic) state.  That would hopefully facilitate experimentation and detailed comparison of the before and after images might provide a clue about the cause.

omegaomegaDeveloperAuthor Commented:
Problem has vanished without a clear explanation.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

  • 5
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now