Confused Form_Activate event

[TimC]

I want to be able to detect when forms are activated and deactivated.
So I used the Form_Activate and Form_Deactivate events. To test it
worked as expected I placed a Debug.print line in each of the event
procedures of the forms I was experimenting with.

The behaviour I observed seems bizzare to me. When clicking on the
form - Nothing. When clicking away from the form - the deactivate
event for the form AND the deactivate event for the SAME form both
fired.

So when I expected the activate form to fire, nothing happened. When I
expected the deactivate event to fire, both the deactivate and the
activate event fired.

Note that these forms are fairly complex with multiple subforms and a
lot of code behind the form.

I then created a very simple form and added the debug.print statements
to its Activate and Deactivate event procedures. Everything worked as
it should ie Activate event fired when form was clicked, Deactivate
fired when form was clicked away from.

So it would appear that something about these complex forms is
confusing Access. Does anyone have experience with this? I would like
to identify specifically what aspects of my forms are confusing Access
and modify so that I end up with the Form_Activate event firing
reliably.

By the way, the deacativate event seems to be reliable from my testing.

 

[Allen Browne]

Tim, I don't have an answer, so hopefully others will contribute if they
have experienced this.

Trouble is, it could be so many different things going on here. Any form's
Timer event can interfere with the flow of events, so that would relate to
any form you have open at the time (including subforms.)

Obviously things like toggling the Visible property of the form could have
an effect. Complex interactions with the subforms could also affect what's
happening to the main form. (I'm assuming you are tracking the events of the
main form here.)

Opening other forms/reports could affect Activate/Deactivate, as could other
commands such as SelectObject, MsgBox, SetFocus. Code in the form's events
could have an effect, particularly Current, Before/After Update/Insert, the
delete events, or the keystroke or mouse events. Requerying,
applying/removing a filter/sort, changing view, going to/from Filter By Form
mode, ...

If you really want to track this down, I suspect you will have to take the
divide'n'conquor approach. Using a copy of the database, dump half the stuff
in the form and see if the problem still occurs. Continue halving until the
problem ceases, then narrow down the stuff in the last half, until you
pinpoint the culprit.

 

[TimC]

Tim, I don't have an answer, so hopefully others will contribute if they
have experienced this.

Trouble is, it could be so many different things going on here. Any form's
Timer event can interfere with the flow of events, so that would relate to
any form you have open at the time (including subforms.)

Obviously things like toggling the Visible property of the form could have
an effect. Complex interactions with the subforms could also affect what's
happening to the main form. (I'm assuming you are tracking the events of the
main form here.)

Opening other forms/reports could affect Activate/Deactivate, as could other
commands such as SelectObject, MsgBox, SetFocus. Code in the form's events
could have an effect, particularly Current, Before/After Update/Insert, the
delete events, or the keystroke or mouse events. Requerying,
applying/removing a filter/sort, changing view, going to/from Filter By Form
mode, ...

If you really want to track this down, I suspect you will have to take the
divide'n'conquor approach. Using a copy of the database, dump half the stuff
in the form and see if the problem still occurs. Continue halving until the
problem ceases, then narrow down the stuff in the last half, until you
pinpoint the culprit.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users -http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.












- Show quoted text -

Thanks for your reply Allen.

The scope of possible causes that you mention is a little
intimidating. It may be easier for me to try a very different
approach.

The reason I wanted to be able to detect Activate and Deactivate
events of forms, was to be able to close down forms, when necessary in
order to free up resources. So if my database receives the 'Can't open
any more databases' error for example,I can pick a form that is no
longer active (and has been nominated by my program as available to be
closed) and close it. This is especially needed when opening one form
from another.

I am considering just using the Deactivate event when nominating those
forms available for closing (I have a way of differentiating between
the Deactivate event firing do to another object being activated and
the form being closed). I will not use the Activate event or any other
event to try and detect when a form becomes the active form. Instead
when it comes time to close a form in order to free resources, I will
test whether the form I am about to close is the Active form (using
Application.Screen.ActiveForm) and only close it if it is not the
active form.

Is Application.Screen.ActiveForm reliable or is it affected by some of
the issues that confuse Form_Activate?

Do know of any other alternative approaches to what I'm trying to do?

I appreciate your help.

Tim

 

[Allen Browne]

In general, Screen.ActiveForm should be accurate (assuming you use error
handling to cover the case where no form is active.)

But again, it will depend on the timing, and it could be affected by other
factors. For example, if you open Form2 from Form1, and examine
Screen.ActiveForm in the Open event of Form2, Form1 might still be the
active one, though if you executed the line:
Me.Visible = True
then Form2 might be the active one in the same event. (That's without
testing.)

The real solution might involve tracking down why you are running out of
resources. I write apps designed to have multiple forms open at once and
rarely see the "too many databases" error, so what's triggering it for you?
Too many combos? Too many DLookup's? Trying to keep all the forms open (not
just those the user actually needs)?

 

[TimC]

In general, Screen.ActiveForm should be accurate (assuming you use error
handling to cover the case where no form is active.)

But again, it will depend on the timing, and it could be affected by other
factors. For example, if you open Form2 from Form1, and examine
Screen.ActiveForm in the Open event of Form2, Form1 might still be the
active one, though if you executed the line:
Me.Visible = True
then Form2 might be the active one in the same event. (That's without
testing.)

The real solution might involve tracking down why you are running out of
resources. I write apps designed to have multiple forms open at once and
rarely see the "too many databases" error, so what's triggering it for you?
Too many combos? Too many DLookup's? Trying to keep all the forms open (not
just those the user actually needs)?

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users -http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.













- Show quoted text -

Thanks again Allen.

I'll try the Me.Visible=True tip to try and ensure Screen.ActiveForm
does pick up what I intend to be the active form.

With regards to for running out of resources, it is not a frequent
problem. It happens when multiple of these complex forms are open at
the same time ie opening one form from another. It does however occur
and so I want to try and resolve it.

I think the fact that it is an issue at all is due to my design
decisions/philosophy. I use a limited number of forms and reports that
are very versatile. This allows the user a lot of flexibility in how
they work with the data but requires a fair number of controls to
implement. The reality is that significantly changing/simplifying the
design of objects is not really an option. The way I see it, my only
real option is to make the forms as efficient as possible and then
handle the infrequent occurances of running out of resources.

I have already taken some steps to minimise resource usage such as
only setting the SourceObject property for some subform controls when
the relevant tab page is selected. I don't use any DLookups at all.
Only a small set of forms is hidden when the user finishes with them,
all others are actually closed.

If you have any other suggestions I would be grateful to hear them.

Thanks for your help.

Tim