Is Access consistent with the order of events when opening a form from within a procedure?

[MLH]

If you have these lines in code on MyForm1...

DoCmd OpenForm "MyForm2`"
MsgBox "I opened MyForm2"

Is it #ALWAYS# true that all form events
on MyForm2 will occur before the MsgBox
statement in MyForm1 is processed?

Is there ever an exception that might create
a race condition in which the MsgBox line
would be processed before one or more of
the MyForm2 events?

[MLH]

Excuse me for leaving off the specific MyForm2
events I was concerned with, they are...
OPEN
LOAD
RESIZE
ACTIVATE
CURRENT

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mon, 22 Dec 2003 10:49:53 -0500, MLH <CR**@NorthState.net> wrote:

If you have these lines in code on MyForm1...

DoCmd OpenForm "MyForm2`"
MsgBox "I opened MyForm2"

Is it #ALWAYS# true that all form events
on MyForm2 will occur before the MsgBox
statement in MyForm1 is processed?

Is there ever an exception that might create
a race condition in which the MsgBox line
would be processed before one or more of
the MyForm2 events?

[Tom van Stiphout]

On Mon, 22 Dec 2003 10:49:53 -0500, MLH <CR**@NorthState.net> wrote:

The use of DoEvents would throw things off.
Also setting Cancel to True in Form_Open.
Perhaps also resizing your form in Form_Open or Form_Load.

-Tom.

If you have these lines in code on MyForm1...

DoCmd OpenForm "MyForm2`"
MsgBox "I opened MyForm2"

Is it #ALWAYS# true that all form events
on MyForm2 will occur before the MsgBox
statement in MyForm1 is processed?

Is there ever an exception that might create
a race condition in which the MsgBox line
would be processed before one or more of
the MyForm2 events?

[Steve Jorgensen]

WFICT, no, there is no case where those events would not all fire prior to the
MsgBox call. However, writing code that depends on sequence is generally good
to avoid if you can think of an easy way to avoid it, because such code tends
to be more modular and cleaner anyway, and because it's bossible that new
versions of the software or new code of yours in the form itself could cause
breakage of the logic.

Example. Occasionally, you find something in Access that you need to do when
a form opens that does not work right when attempted from either the Open or
Load events, so you set up a 1ms timer, and call it from there. Now, even
though Access would perform as expected, you have still broken the calling
code by moving the logic.

Of course, using the timer event, then, is another thing you want to try to
avoid for musch the same reason, but the point is that if you can avoid
strenuous expectations by any part of the code, you have more slack elsewhere
if you need it.

On Mon, 22 Dec 2003 10:57:07 -0500, MLH <CR**@NorthState.net> wrote:

Excuse me for leaving off the specific MyForm2
events I was concerned with, they are...
OPEN
LOAD
RESIZE
ACTIVATE
CURRENT

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mon, 22 Dec 2003 10:49:53 -0500, MLH <CR**@NorthState.net> wrote:

If you have these lines in code on MyForm1...

DoCmd OpenForm "MyForm2`"
MsgBox "I opened MyForm2"

Is it #ALWAYS# true that all form events
on MyForm2 will occur before the MsgBox
statement in MyForm1 is processed?

Is there ever an exception that might create
a race condition in which the MsgBox line
would be processed before one or more of
the MyForm2 events?

[David W. Fenton]

CR**@NorthState.net (MLH) wrote in
<4m********************************@4ax.com>:

If you have these lines in code on MyForm1...

DoCmd OpenForm "MyForm2`"
MsgBox "I opened MyForm2"

Is it #ALWAYS# true that all form events
on MyForm2 will occur before the MsgBox
statement in MyForm1 is processed?

Is there ever an exception that might create
a race condition in which the MsgBox line
would be processed before one or more of
the MyForm2 events?

Successive lines of code executed asynchronously, so, the
MessageBox could fire before all the events of the form opening
would fire.

A kludgy way to force it would be:

DoCmd OpenForm "MyForm2", , , , , acDialog
[in the form's Activate event, set Me.Visible = False]
MsgBox "I opened MyForm2"
Forms!MyForm2.Visible = True

Of course, at that point, it's still a dialog form.

And I can't guarantee that this will always work.

If you really want code to execute only after a form has finished
opening, the code needs to be in the last relevant event of the
form. And, even then, you can't control it for sure, as other
things can intervene.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[MLH]

Interesting!
xxxxxxxxxxxxxxxxxx
On Mon, 22 Dec 2003 09:12:22 -0700, Tom van Stiphout
<to*****@no.spam.cox.net> wrote:

On Mon, 22 Dec 2003 10:49:53 -0500, MLH <CR**@NorthState.net> wrote:

The use of DoEvents would throw things off.
Also setting Cancel to True in Form_Open.
Perhaps also resizing your form in Form_Open or Form_Load.

-Tom.

If you have these lines in code on MyForm1...

DoCmd OpenForm "MyForm2`"
MsgBox "I opened MyForm2"

Is it #ALWAYS# true that all form events
on MyForm2 will occur before the MsgBox
statement in MyForm1 is processed?

Is there ever an exception that might create
a race condition in which the MsgBox line
would be processed before one or more of
the MyForm2 events?

[Steve Jorgensen]

On Mon, 22 Dec 2003 18:19:26 GMT, dX********@bway.net.invalid (David W.
Fenton) wrote:

CR**@NorthState.net (MLH) wrote in
<4m********************************@4ax.com>:

If you have these lines in code on MyForm1...

DoCmd OpenForm "MyForm2`"
MsgBox "I opened MyForm2"

Is it #ALWAYS# true that all form events
on MyForm2 will occur before the MsgBox
statement in MyForm1 is processed?

Is there ever an exception that might create
a race condition in which the MsgBox line
would be processed before one or more of
the MyForm2 events?
Successive lines of code executed asynchronously, so, the
MessageBox could fire before all the events of the form opening
would fire.

Access does many things aynchronously, but I have yet to notice a case when
the next statement after an OpenForm could fire before all of the initial form
open events (not that I advocate relying on this).

One certainly must be careful with things like expecting a table or report
export to be completed before trying to do something with the resulting file.
In this case, adding a singe DoEvents call will force VBA to wait until the
export completes.
A kludgy way to force it would be:

DoCmd OpenForm "MyForm2", , , , , acDialog
[in the form's Activate event, set Me.Visible = False]
MsgBox "I opened MyForm2"
Forms!MyForm2.Visible = True

Of course, at that point, it's still a dialog form.

And I can't guarantee that this will always work.

If you really want code to execute only after a form has finished
opening, the code needs to be in the last relevant event of the
form. And, even then, you can't control it for sure, as other
things can intervene.

I generally have good luck using the On Current event handler for these cases,
and making sure one of the controls' value property can be accessed without
error. On Current is usually called once or twice before the recordset is
loaded, but once the Value properties are accessible, everything is ready to
roll.

[TC]

The others have said no, in the absence of a doevents, the open/load etc.
events will fire before you get to the messagebox. But IMO, this is not
because ms designed it that way. It is a (probably not deliberate)
side-effect of the fact that VBA is single-threaded. The thread in question
is busy opening the called form; there is just no other thread available for
the msgbox. But if the called form does a doevents, that thread stops, & all
sorts of curious race conditions can happen then.

HTH,
TC
"MLH" <CR**@NorthState.net> wrote in message
news:4m********************************@4ax.com...

If you have these lines in code on MyForm1...

DoCmd OpenForm "MyForm2`"
MsgBox "I opened MyForm2"

Is it #ALWAYS# true that all form events
on MyForm2 will occur before the MsgBox
statement in MyForm1 is processed?

Is there ever an exception that might create
a race condition in which the MsgBox line
would be processed before one or more of
the MyForm2 events?

[MLH]

Now that's what I'm talkin' about. I never put my finger
on it but, deja vu, I seem to remember encountering
strange effects I could never put my finger on. I couldn't
replicate them (weary from the work-around battle) and
I ended up forgetting about the situation. I'm going to
do some testing around your comments... Thx.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxx
On Tue, 23 Dec 2003 14:49:37 +1200, "TC" <a@b.c.d> wrote:

The others have said no, in the absence of a doevents, the open/load etc.
events will fire before you get to the messagebox. But IMO, this is not
because ms designed it that way. It is a (probably not deliberate)
side-effect of the fact that VBA is single-threaded. The thread in question
is busy opening the called form; there is just no other thread available for
the msgbox. But if the called form does a doevents, that thread stops, & all
sorts of curious race conditions can happen then.

HTH,
TC
"MLH" <CR**@NorthState.net> wrote in message
news:4m********************************@4ax.com.. .

If you have these lines in code on MyForm1...

DoCmd OpenForm "MyForm2`"
MsgBox "I opened MyForm2"

Is it #ALWAYS# true that all form events
on MyForm2 will occur before the MsgBox
statement in MyForm1 is processed?

Is there ever an exception that might create
a race condition in which the MsgBox line
would be processed before one or more of
the MyForm2 events?

[Tom van Stiphout]

On Tue, 23 Dec 2003 21:34:45 -0500, MLH <CR**@NorthState.net> wrote:

Doevents should be used very sparingly, and judiciously.

I once was called to a job where the app was doing "weird
unreproducible things". Within an hour it worked again, after I did a
global find & replace for DoEvents with 'DoEvents (commenting out
several dozen occurrences).
I spent a bit more time inspecting each one, and eventually
uncommented one or two.

-Tom.

Now that's what I'm talkin' about. I never put my finger
on it but, deja vu, I seem to remember encountering
strange effects I could never put my finger on. I couldn't
replicate them (weary from the work-around battle) and
I ended up forgetting about the situation. I'm going to
do some testing around your comments... Thx.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxx
On Tue, 23 Dec 2003 14:49:37 +1200, "TC" <a@b.c.d> wrote:

The others have said no, in the absence of a doevents, the open/load etc.
events will fire before you get to the messagebox. But IMO, this is not
because ms designed it that way. It is a (probably not deliberate)
side-effect of the fact that VBA is single-threaded. The thread in question
is busy opening the called form; there is just no other thread available for
the msgbox. But if the called form does a doevents, that thread stops, & all
sorts of curious race conditions can happen then.

HTH,
TC
"MLH" <CR**@NorthState.net> wrote in message
news:4m********************************@4ax.com. ..

If you have these lines in code on MyForm1...

DoCmd OpenForm "MyForm2`"
MsgBox "I opened MyForm2"

Is it #ALWAYS# true that all form events
on MyForm2 will occur before the MsgBox
statement in MyForm1 is processed?

Is there ever an exception that might create
a race condition in which the MsgBox line
would be processed before one or more of
the MyForm2 events?