Form_Open cancelled "delayed" !?

[Michel S.]

posted this yesterday in the general forum but since I haven't foud a
solution, I submit my problem here, where it belongs. Sorry.


I'm using Access 2002.


I have a form with the following code in its Open event :


Private Sub Form_Open(Cancel As Integer)

If IsOkToProceed = False Then
MsgBox "Can't use this form now - Open canceled"
Cancel = True
End If

End Sub


The IsOkToProceed return false (I added the MsgBox to verify it) and
cancel is set to true.

If I Open the form directly from the database window, it correctly
displays the message and return to the datatbase window.


But if I open the form with the following code located behing another
form, I noted that even if Cancel is set to true in the Open event, the
form's code execution continues with the "Load" event, etc.. until it
fails at the end of the "Current" event. (I set MsgBox in these events
as well to make sure they were executed in that case but not when
opened from the database window)

Private Sub cmdImport_Click()

On Error Resume Next
DoCmd.OpenForm Form_ImportData, acNormal, , , acFormReadOnly, _
acWindowNormal
MsgBox Err.Number ' <-- displays 2001

End Sub


BTW, if I remove the "On Error" statement, the message dispalyed is
"Error 2001 - Error set by application or object"; isn't it supposed to
be "Error 2001 - You canceled the previous operation" ?).


The problem is that the load and current events perform operations I
don't want to do if the form can't be used. I always can avoid this by
setting a module flag, but why work around things that aren't supposed
to occur on the first place ?

I tried to decompile and import the forms and modules in another
database container, but at no avail.


Any idea ?

Thanks

 

[Allen Browne]

As you found the order of events when you open a form does not always follow
the sequence that Microsoft published.

I believe that this is due to the fact that Microsoft has tried to make the
events too flexible. If the events were handled rigidly, you should not be
able to use the Open event of the form to test if it has any records, since
the Load event has not fired yet, so it could not possibly have any records
yet. In practice that is not the case: you can actually get away with
testing if there are records, testing values and so on. But if you do, you
are implicitly forcing Access actually load the records into the form, and
even into the controls. If Access lets us get away with doing that, it
should not be surprising that we are actually forcing those other events to
fire also, and so the sequence of events becomes unpredictable.

The module-level flag sounds like a reasonable way to handle it.

 

[Michel S.]

Thanks for your reply.

Do you have any idea on why it works correctly when opened from the
database window but not from the DoCmd.OpenForm command ? In both
cases, the tested data and conditions are exactly the same.


BTW, the form is bound to an "application parameters" table containing
one record which always exists.

The test I perform in the Open event consists in looking if a required
operation have been executed before - nothing related to the bound
fields.


If one should avoid testing fields or values in the open event to
prevent other events to fire ""at random"", what's the remaining
possible use of cancelling the open event ?

And if I want to perform my tests and prevent using the form in a clean
and reliable way, what should I do ? Perform the test in the load
event and force the form to close from there ?

Thanks again.


Allen Browne a pensé très fort :

 

[Allen Browne]

Michel, there is no problem with the approach you have taken.

Run all the tests you want in Form_Open. All I am suggesting is that the
events are doing more than we might expect, and confirming your experience
that the events don't always fire in the order you expect (or even the
number of times you expect.) The form-level variable is fine.

I am not able to give you a full trace on what's happening with these
events. If anyone else can, please feel free to jump in (as always.)