OnLoad event not firing (1 Viewer)

SyntaxSocialist

Registered User.
Local time
Today, 18:49
Joined
Apr 18, 2013
Messages
109
Form Corrupt? OnLoad event not firing

I have a form w/ subform. Both have event procedures tied to their respective OnCurrent events. What I'm trying to do is, when the main form loads, run a Public subprocedure that lives in the module for the main form. I've been able to create click events that successfully run the sub.

The problem is that the main form's OnLoad event isn't firing.

I've put in some break points and have been able to verify that the OnCurrent events work just fine, and so does the OnLoad event of the subform.

Even more perplexing: the main form's OnLoad event does fire when I close the form (and the subform's doesn't)! WHAT? :confused:

Can someone help me understand why I'm having this problem?

EDIT: AHA! So now I've discovered that the main form's OnLoad event fires as soon as I click into a control. Obviously, I want it to fire before that. Any ideas about the cause or a workaround?
 
Last edited:

missinglinq

AWF VIP
Local time
Today, 18:49
Joined
Jun 20, 2003
Messages
6,423
...EDIT: AHA! So now I've discovered that the main form's OnLoad event fires as soon as I click into a control...

That shouldn't be happening! It should be firing...when the Form loads! This, plus the Form_Load firing when you go to close the Form, makes me think that the Form is corrupted.

Linq ;0)>
 

SyntaxSocialist

Registered User.
Local time
Today, 18:49
Joined
Apr 18, 2013
Messages
109
That shouldn't be happening! It should be firing...when the Form loads! This, plus the Form_Load firing when you go to close the Form, makes me think that the Form is corrupted.

NOOOOOOOOO! :eek: :(

How can I check to see if this is the case and start towards fixing it?

EDIT2
Additional clarity achieved:The OnLoad event for the main form fires on closing only if I have not already clicked into another control. So it's not firing on click-in and on close, but just on whichever happens first.
 
Last edited:

missinglinq

AWF VIP
Local time
Today, 18:49
Joined
Jun 20, 2003
Messages
6,423
In the Form_Load for the Main Form add

Msgbox "Main Form/Form Load has Fired!"

Save, Close then re-open the Form; you should see the Messagebox when it initially opens.

Linq ;0)>
 

SyntaxSocialist

Registered User.
Local time
Today, 18:49
Joined
Apr 18, 2013
Messages
109
In the Form_Load for the Main Form add

Msgbox "Main Form/Form Load has Fired!"

Save, Close then re-open the Form; you should see the Messagebox when it initially opens.

Linq ;0)>

Nope. The messagebox doesn't appear until I click-in or close :(

Not very surprising, given what I was experiencing when I had the breakpoints in place.
 

missinglinq

AWF VIP
Local time
Today, 18:49
Joined
Jun 20, 2003
Messages
6,423
Sounds like corruption, then. Create a new file and Import everything into it and see if that works.

Linq ;0)>
 

SyntaxSocialist

Registered User.
Local time
Today, 18:49
Joined
Apr 18, 2013
Messages
109
Sounds like corruption, then. Create a new file and Import everything into it and see if that works.

Augh. No luck.

I've never done that before, though, so let me tell you what I did to make sure I didn't muck up at any point.

(I'm on Access 2007)

My db has a front end that I keep on the network drive associated with my work PC. The FE references the BE tables, which are located in a file on the office's "public" network drive.

I created a blank db, went to the External Data tab, and clicked "Access" in the Import group. This launched a wizard. I made sure the selected option was "Import tables, queries, forms, reports, macros, and modules into the current database," rather than "Link to the data source by creating a linked table." I specified the data source as the FE file and selected all tables (mostly linked), forms, queries, macros, and modules.

I didn't do this with the BE as well; it seems clear to me the problem is in the FE.​

Did I do it right? :p

I've read in a few places that when corruption of this sort occurs, decompiling can be a solution... though I'm not sure about what that means or how to go about it. The resources I found were a little over my head, so if that's the next step forward, I may need a bit more guidance than I've been able to find so far on forums...
 
Last edited:

Pat Hartman

Super Moderator
Staff member
Local time
Today, 18:49
Joined
Feb 19, 2002
Messages
42,976
Keep in mind that the subform events fire BEFORE the mainform events when the form is loading.

Form events are influenced by whether or not the form has any controls that can receive the focus. That may explain why the load event doesn't run until you click into the subform. Try adding an unbound control to the main form and see if that changes the event execution.
 

SyntaxSocialist

Registered User.
Local time
Today, 18:49
Joined
Apr 18, 2013
Messages
109
Keep in mind that the subform events fire BEFORE the mainform events when the form is loading.

Form events are influenced by whether or not the form has any controls that can receive the focus. That may explain why the load event doesn't run until you click into the subform. Try adding an unbound control to the main form and see if that changes the event execution.

There are loads of unbound controls on the main form already. Textboxes, comboboxes, option groups, checkboxes... I use them to dynamically build a WHERE clause to filter the subform's displayed results.

The issue is more that Access doesn't even "step in" to the Load event; it's not just skipping over the code in the event, but rather over the event itself.

EDIT 3: I added an Open event, and it fires as expected. I put a few lines into the Open event to make sure my controls could receive the focus (there's another sub that could have maybe prohibited that). The Form_Open sub runs just fine, but Form_Load still does nothing until click-in or close.

At this point, should I just use the Open event instead? The code in the Load event doesn't require the recordsource to be loaded. Or would leaving the kind of corruption that exists here be a slippery slope to a deteriorating form/db?
 
Last edited:

missinglinq

AWF VIP
Local time
Today, 18:49
Joined
Jun 20, 2003
Messages
6,423
I would try simply deleting the Form_Load event and recreating it, but not using copy & paste; do that elsewhere, like in Word, if it's complicated enough for you to want it to reference it.

If the code doesn't require the RecordSet, the Open Event should be OK.

Linq ;0)>
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 18:49
Joined
Feb 19, 2002
Messages
42,976
Try to export the form and then reimport it to get rid of corruption.

Application.SaveAsText acForm, "yourformname", "fullpathwhereformisexportedto" & "yourformname" & ".txt"

Compact and repair the database and then reopen.

CApplication.Application.LoadFromText acForm, "yourformname", "fullpathwhereformisexportedto" & "yourformname" & ".txt"
 

SyntaxSocialist

Registered User.
Local time
Today, 18:49
Joined
Apr 18, 2013
Messages
109
Sorry for the delay in response.

I would try simply deleting the Form_Load event and recreating it, but not using copy & paste; do that elsewhere, like in Word, if it's complicated enough for you to want it to reference it.

If the code doesn't require the RecordSet, the Open Event should be OK.

I thought I had already done that once or twice, but for good measure I tried once more. No luck :(

The more I think about it, the more uncomfortable I am with letting the corruption just sit there. If at all possible, I'd like to work through this issue rather than around it.

Try to export the form and then reimport it to get rid of corruption.

Application.SaveAsText acForm, "yourformname", "fullpathwhereformisexportedto" & "yourformname" & ".txt"

Compact and repair the database and then reopen.

CApplication.Application.LoadFromText acForm, "yourformname", "fullpathwhereformisexportedto" & "yourformname" & ".txt"

Pat: this looks like it would be very helpful. You'll have to forgive me, though: I'm not totally clear on where I'm putting that code... the command line? Any further instruction you could provide would be greatly appreciated.

EDIT4: Did some digging. Immediate window. My bad. This page helped me to sort out what you meant. Unfortunately, no luck. :banghead:

Keep in mind that the subform events fire BEFORE the mainform events when the form is loading.

Humm... perhaps the problem is actually being caused by code in the subform, then... Will try your suggestion on that form as well and report back.

EDIT 5: Nope.

But something I should maybe also mention: If I don't click-into a form control, but instead switch to design view, I get Run-time error 2474: "The expression you entered requires the control to be in the active window." The same thing occurs when I close the form without first clicking-in. I imagine it's just because the Load event is trying to run on a form that is no longer active (because it's closed or not in Form view), especially since the error doesn't occur when I click-in, but I figured this might be worth mentioning, anyway, in case I'm missing something.
 
Last edited:

SyntaxSocialist

Registered User.
Local time
Today, 18:49
Joined
Apr 18, 2013
Messages
109
SOLVED!

So in a last-ditched attempt to see if the issue wasn't one of corruption, I started commenting out all manner of procedures (and entire modules) to see if that would resolve the issue.

It did!

The culprit turned out to be the Current event in the subform:
- The subform Current event called a public sub from a general module.
- That public sub ensures that the active record in the subform and main form reflect one another (like in a split form)
- When the public sub changed the main form's active record, it triggered the main form's Current event, which normally runs after its Load event.

So I guess Access was tricking itself into thinking that the Load event had already run? I'm not totally clear on why it would then run on click-in or close, but the good news is that the issue is resolved and my form is not corrupt (and if it was, it ain't no more)!

Solution: Use the Open event.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 18:49
Joined
Feb 19, 2002
Messages
42,976
I'm not sure why you think you need that code at all if you are using bound forms so removing it will eliminate the problem. It was conflicting with the normal sequence of events that Access uses when it loads forms. I'm surprised nothing worse happened.

If you put a stop in one of the subform events, save the form and reopen it, you should be able to step through the subform events, then the public sub, then the mainform events.
 

SyntaxSocialist

Registered User.
Local time
Today, 18:49
Joined
Apr 18, 2013
Messages
109
I'm not sure why you think you need that code at all if you are using bound forms so removing it will eliminate the problem. It was conflicting with the normal sequence of events that Access uses when it loads forms. I'm surprised nothing worse happened.

If you put a stop in one of the subform events, save the form and reopen it, you should be able to step through the subform events, then the public sub, then the mainform events.

The reason lies in the fact that I want the subform and main form to reflect one another, as in a split form. I found split forms to be wildly unrobust, so I set out to emulate their behaviour. Now, if the user selects a record in the subform, the bound controls in the main form display that record, and if the user navigates to a particular record in the main form, the subform displays that record, too. It took me forever to get this working properly, and I'm not about to throw all that away.

As for the stop in the subform events: Nope. Still won't enter the Load event. I agree that this is far from ideal, but the behaviour is predictable, at least. No event fires on click-in or close, though, because I've now removed the Load event altogether.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 18:49
Joined
Feb 19, 2002
Messages
42,976
When the subform controls the main form as yours does, the main form should open "blank". Then when you click on a record in the subform, your code should sync them.

My approach is simple (no banging your head against the wall or pulling out your hair). The mainform has a hidden control that holds the ID of the subform record. Since it is empty when the form opens, the main form opens blank. The master/child link is not used for this process since Access expects the master to control the child. Instead, the RecordSource of the main form references the hidden ID field for its selection criteria. So the only line of code necessary is a requery of the parent form executed in the Current event of the subform after the ID field is populated.

Code:
Me.Parent.txtSubformPK = Me.SubformPK
Me.Parent.Requery
 

SyntaxSocialist

Registered User.
Local time
Today, 18:49
Joined
Apr 18, 2013
Messages
109
When the subform controls the main form as yours does, the main form should open "blank". Then when you click on a record in the subform, your code should sync them.

My approach is simple (no banging your head against the wall or pulling out your hair). The mainform has a hidden control that holds the ID of the subform record. Since it is empty when the form opens, the main form opens blank. The master/child link is not used for this process since Access expects the master to control the child. Instead, the RecordSource of the main form references the hidden ID field for its selection criteria. So the only line of code necessary is a requery of the parent form executed in the Current event of the subform after the ID field is populated.

Code:
Me.Parent.txtSubformPK = Me.SubformPK
Me.Parent.Requery

Sounds wonderfully simple. But I can't get the form to let me make the recordsource anything but a table or query...
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 18:49
Joined
Feb 19, 2002
Messages
42,976
The RecordSource is a query and that query has criteria that refers to the hidden field.
 

Users who are viewing this thread

Top Bottom