MSACCESS VBA object Order

[BJZeak]

Several years ago I wrote a generic Start Module which provides user Login/Password, Auto Hide, Remote Shutdown/Lockout and User Level features that could be easily adapted to existing Main Forms ... am using this on several 2003/2016 db application files and allows for nightly orderly shutdowns prior to backups ... unfortunately I ran out of time during the initial project so never completed any of the downstream user level logic. ... at present I need to now add user level restrictions to an existing Main Form

Consider the Start Logic just runs in the background as a hidden Object and contains Global Values for Machine, User, and User Level

The main form I am working with consists of a sidebar with a number of option group buttons and the main part of the form consists of several overlaid Subforsms (one subform for each button minus the exit button) The control logic for the Option Group selects the appropriate subform by making it visible then hides the rest of the subforms.

What has me stumped is: my expectation is that the Main Form Form_Open/Form_Load logic would run before any of it's subforms ... I actually peppered all the subforms and main/parent form with debug.print statements and to my dismay the MainForm is not even being called until after I click one of the buttons

The default subform is visible by default so the form does appear to work properly in spite of not having run the main Form_load routine ... the other curiosity is the Form_load that is being run first is for a subform that has visible set to false

for the user level logic to work, the main form load must determine which buttons on the option group are not allowed for a specific level ... if the main form_load isn't being run then all the buttons are available

Thoughts on how I can determine/fix/force the order that ACCESS fires the Form_load routines? Would I need to use a global State Machine flag that aborts a Form_load if it runs before its expected state? With the overlay subforms I could well imagine all of the forms initially loading but still expect the main form Load to occur first.

Neither seems to be happening ... there is only one form_load firing for this invisible subform ... could this situation have something to do with the Send to Back/Front functionality? Even though the form that is loading is set to invisible perhaps it is the topmost form? How can I prove that ... hmm maybe set visible to true and see if it pops up on load

 

[dhookom]

I expect the first code running might be from the first subform you added to the main form. I would not attempt to fight the order the code runs. I would set all of the subforms to invisible and main form controls that might change to their most locked down state. Then save everything. Use the main form code to set up everything based on your security.

Duane
Minnesota
Hook'D on Access
MS Access MVP 2001-2016

 

[BJZeak]

As stated, the order in which Access is firing these layered subforms is totally incomprehensible ... tried a number of mods to ascertain the nature of the order and or change the order to no avail ... order remained unchanged

Warning KLUDGE Solution:

Ended up adding a global STATE flag which is set at application startup and isn't cleared until the Main Form Menu's form_load runs. This flag, coupled with adding

 IF gloPendingStart THEN EXIT SUB

to the beginning of each ROUGE sub form event (determined by debug.print statements peppered throughout the subform events) appears to have masked the load problem by basically bypassing all events being called before the menu form_load event.

The menu's form_load is now finally running prior to the Option Group rendering with the expected user level restrictions plus all of the layered subforms still working properly

I don't like Kludge solutions but without being able to determine the reason(s) for the bizar load order I think this time the Kludge wins.

 

[Andrzejek]

One way to determine the order of events firing is to set up a simple, almost empty application with just a few command buttons and trace the order of events. You may find out that “the reason(s) for the bizar load order” could be your code. For example, when you populate a combo box in the code (by cboMyCombo.AddItem) and then at the end you assign cboMyCombo.ListIndex = 0 or cboMyCombo.Text = “Whatever”, that triggers Click event of cboMyCombo to fire. Or you set the Value = True of an option (radio) button, that fires its Click event.

Just a suggestion…



---- Andy

There is a great need for a sarcasm font.

 

[dhookom]

Again, I would set all of the subforms to invisible until the main form code is run. You can also call the on load events for each subform from the on load of the main form.

Duane
Minnesota
Hook'D on Access
MS Access MVP 2001-2016

 

[BJZeak]

Duane
the one/dominant/topmost subform that is visible wasn't being called ... the MAIN MENU FORM form_load was not called until there was user activity ... too late in the game

Andy
I have no doubt there is some relation to some code/configuration ... unfortunately so far this has been like looking for a needle in a haystack

 

[strongm]

>my expectation is that the Main Form Form_Open/Form_Load logic would run before any of it's subforms

This expectation, as you have found, is wrong. The lowest form in any form hierarchy generates its events first. Those at the same level in the hierarchy will go the order they are in the parent form's Controls collection. The following code, placed in a module, should display the form order for the events if you pass the form at the top of the hierarchy to it:

[blue]Public Sub ListSubs(rootfrm As Form)
    Dim ctl As Control
    
    For Each ctl In rootfrm.Controls
        If ctl.Properties("ControlType") = acSubform Then
            ListSubs ctl.Form
        End If
    Next
    Debug.Print rootfrm.Name
End Sub[/blue]

This doesn't explain why you are not getting your main form's load event, however … one possibility is that the form has somehow lost the link to the event procedure. Can you try checking the OnLoad property of the Form is set to [Event procedure]. if it isn't then, reconnect by selecting [Event procdure] from the dropdown menu. If it is, click the … to ensure you are taken to the relevant VBA code.

 

[dhookom]

I wonder if the lack of the main form's "load" event is because it's unbound. An interesting test would be to bind the main form to a simple, single record, read-only query.

Duane
Minnesota
Hook'D on Access
MS Access MVP 2001-2016

 

[BJZeak]

strongm,

Thanks for giving me a well deserved KICK ... your comment triggered a vague recollection that I had done investigations into the Hierarchical order of events some time after switching away from FOXPRO in the late 90's ... 45 years of coding across various systems (embedded machine code to enterprise db's), thinking I'm getting too old for this game.

Ran a variation of your code that revealed the actual stored sequence of Form objects ... the listing confirms the event order I was seeing ... the apparent bizar nature of the event order, (guessing), may be due to events running concurrently and not completing before others finish. ie subfrm 1 has 3 events interlaced with subfrms 2 and 3 events

Expecting the lack of the MENU form_load not firing may indicate that one of the subform events is waiting for something

As all of thees subforms were developed separately over time (several years) and were consolidated in to one application with the Option Group Selector. Which by kludging the events that are firing at startup now works the way it was intended

Duane,

The Menu Form_Load is in the Event list ... as pointed out by Andy, the event is most likely being held up by the coding of the subforms. I will add a Query to lookup a config param which should determine if the kludge filters are necessary