How to detect when user switches between open forms?

[Vexen Crabtree]

The user can have multiple non-modal, restored, forms open at once and can
switch between them as they want, often by just clicking on their titlebars.
These forms are all instances of F_URL. I am using Vista, Access 2007.

How do I run a routine anytime the user switches form?

F_URL.GotFocus doesn't fire because the Focus event only fires for the
particular control that has the focus on the form, and, there are many such
possible controls. F_URL.Activate doesn't fire.

So, four possibilities as far as I can see:

1. There is probably some obvious event that I'm just missing!

2. If not, how do people get around this? One way I've thought of is using a
timer but it seems an incredible use of resources to have it run (say) every
500ms to detect the active form, see if it has changed since the last time
the code was ran, and then to run it. And... I'd have to have a hidden form
permanently open to actually run the timer. Is there a better way?

3. Should F_URL.Activate be firing when the user switches form? I've checked
(and stepped-through) the app looking for anything that might interfere with
..Activate but there doesn't seem to be anything.

4. I *could* have a button on each form that the user clicks in order to run
the code after they've switched form. But I know that they'll forget, won't
see the point, and will complain about having to do it!

Does anyone have an *elegant* way of detecting when the user has switched
between already-open forms?

 

[Lynn Trapp]

Take a look at the Activate event of the form.

 

[Vexen Crabtree]

The following code in the form F_URL

Private Sub Form_Activate()
MsgBox "Here"
End Sub

never seems to run, either when the form is loaded for the first time, or
when a user swithces to any of the open instances of F_URL. I've already been
looking at this, which is why I asked in point 3 in my post if anyone knows
anything that could be stopping it from running? In Design mode, I have made
sure that the form lists "[Event Procedure]" as the property for the Event
(as sometimes when you write code directly, it won't notice).

 

[Lynn Trapp]

Is this happening only to that one form? Or does it happen with all forms?

--
Lynn Trapp
Trainer/Application Developer

The following code in the form F_URL

Private Sub Form_Activate()
MsgBox "Here"
End Sub

never seems to run, either when the form is loaded for the first time, or
when a user swithces to any of the open instances of F_URL. I've already
been
looking at this, which is why I asked in point 3 in my post if anyone
knows
anything that could be stopping it from running? In Design mode, I have
made
sure that the form lists "[Event Procedure]" as the property for the Event
(as sometimes when you write code directly, it won't notice).

Take a look at the Activate event of the form.

--
Lynn Trapp
Trainer/Application Developer


message

 

[Vexen Crabtree]

Thank you for your quick responses by the way.

You ask a good question, I hadn't checked if it worked for other forms. It
does run when forms are loaded for the first time (which is an easy event to
catch anyway), but not when the user switches between open forms, which seems
to be a strangely hard event to catch.

Is this happening only to that one form? Or does it happen with all forms?

--
Lynn Trapp
Trainer/Application Developer

The following code in the form F_URL

Private Sub Form_Activate()
MsgBox "Here"
End Sub

never seems to run, either when the form is loaded for the first time, or
when a user swithces to any of the open instances of F_URL. I've already
been
looking at this, which is why I asked in point 3 in my post if anyone
knows
anything that could be stopping it from running? In Design mode, I have
made
sure that the form lists "[Event Procedure]" as the property for the Event
(as sometimes when you write code directly, it won't notice).

Take a look at the Activate event of the form.

--
Lynn Trapp
Trainer/Application Developer


message
The user can have multiple non-modal, restored, forms open at once and
can
switch between them as they want, often by just clicking on their
titlebars.
These forms are all instances of F_URL. I am using Vista, Access 2007.

How do I run a routine anytime the user switches form?

F_URL.GotFocus doesn't fire because the Focus event only fires for the
particular control that has the focus on the form, and, there are many
such
possible controls. F_URL.Activate doesn't fire.

So, four possibilities as far as I can see:

1. There is probably some obvious event that I'm just missing!

2. If not, how do people get around this? One way I've thought of is
using
a
timer but it seems an incredible use of resources to have it run (say)
every
500ms to detect the active form, see if it has changed since the last
time
the code was ran, and then to run it. And... I'd have to have a hidden
form
permanently open to actually run the timer. Is there a better way?

3. Should F_URL.Activate be firing when the user switches form? I've
checked
(and stepped-through) the app looking for anything that might interfere
with
.Activate but there doesn't seem to be anything.

4. I *could* have a button on each form that the user clicks in order
to
run
the code after they've switched form. But I know that they'll forget,
won't
see the point, and will complain about having to do it!

Does anyone have an *elegant* way of detecting when the user has
switched
between already-open forms?

 

[Dirk Goldgar]

Thank you for your quick responses by the way.

You ask a good question, I hadn't checked if it worked for other forms. It
does run when forms are loaded for the first time (which is an easy event
to
catch anyway), but not when the user switches between open forms, which
seems
to be a strangely hard event to catch.

I am not able to reproduce this behavior in Access 2003. It could be a bug
(or "by design" change of behavior) in Access 2007, but before concluding
that, could you please confirm that VBA is in fact enabled in the database
in question? Do other VBA procedures run in that database? I ask because
Access 2007 is ... cautious ... about allowing VBA to execute, unless the
database is in a trusted location.

Am I right in understanding that the forms are all non-default instances of
the same form class? So you have instantiated them by code along the lines
of "Set frmA = New Form_F_URL"?

 

[Vexen Crabtree]

I am not able to reproduce this behavior in Access 2003. It could be a bug
(or "by design" change of behavior) in Access 2007, but before concluding
that, could you please confirm that VBA is in fact enabled in the database
in question? Do other VBA procedures run in that database? I ask because
Access 2007 is ... cautious ... about allowing VBA to execute, unless the
database is in a trusted location.

Am I right in understanding that the forms are all non-default instances of
the same form class? So you have instantiated them by code along the lines
of "Set frmA = New Form_F_URL"?

VBA is definately enabled, and many other routines and functions, commands
and events all run smoothly on this particular form, and on others.

The form in question (F_URL) is always instantiated by a routine in global
module, and a reference to the form is held in a global collection.

The following is all in "M_Global":

Public OwnURLFormsCollection As New Collection

Public Function EditPage(ByVal epID As Integer)
Dim epForm As Form_F_URL
If Nz(epID, 0) = 0 Then Exit Function

Set epForm = ReturnF_URL_ForURLIfAlreadyOpen(epID)
If Not (epForm Is Nothing) Then 'Already open
epForm.SetFocus
Else
Set epForm = New Form_F_URL
epForm.OpenPage epID
OwnURLFormsCollection.Add epForm 'Keeps the form open
End If

Set epForm = Nothing
End Function

The "OpenPage" function does a few things, including me.setfocus and
me.visible=true, and sets some values on control buttons, which all work.

F_URL.Activate doesn't run after the line "Set epForm = New Form_F_URL" or
when switching between open windows (which is where I most need to run code!).

I have found ways around having to detect when the form changes, but there
are still a few functions that require it.

 

[Dirk Goldgar]

VBA is definately enabled, and many other routines and functions, commands
and events all run smoothly on this particular form, and on others.

The form in question (F_URL) is always instantiated by a routine in global
module, and a reference to the form is held in a global collection.

The following is all in "M_Global":

Public OwnURLFormsCollection As New Collection

Public Function EditPage(ByVal epID As Integer)
Dim epForm As Form_F_URL
If Nz(epID, 0) = 0 Then Exit Function

Set epForm = ReturnF_URL_ForURLIfAlreadyOpen(epID)
If Not (epForm Is Nothing) Then 'Already open
epForm.SetFocus
Else
Set epForm = New Form_F_URL
epForm.OpenPage epID
OwnURLFormsCollection.Add epForm 'Keeps the form open
End If

Set epForm = Nothing
End Function

The "OpenPage" function does a few things, including me.setfocus and
me.visible=true, and sets some values on control buttons, which all work.

F_URL.Activate doesn't run after the line "Set epForm = New Form_F_URL" or
when switching between open windows (which is where I most need to run
code!).

Hmm. Now I've tried it in Access 2007, in a simple setup with module-level
form variables set to instances of the same form, with a MsgBox coded in
that forms Activate event. This worked fine for me, exactly as I would have
exected. The Msgbox for each instance fired when I first instantiated the
form, and also whenever I clicked from one form to another.

HOWEVER, it did not fire if the form's PopUp property was set to Yes (True).
I recall this from the behavior of ordinary, default instances of forms --
the Activate event doesn't fire for PopUp forms. Is your form F_URL a popup
form, by any chance?

 

[Vexen Crabtree]

HOWEVER, it did not fire if the form's PopUp property was set to Yes (True).
I recall this from the behavior of ordinary, default instances of forms --
the Activate event doesn't fire for PopUp forms. Is your form F_URL a popup
form, by any chance?

YES, that is it!!! When I set PopUp to false in design time, the Activate
event then fires.

But when PopUp is false the form always opens Maximized. There are no
Minimize or Restore buttons, and, if I stick DoCmd.Restore in the Activate
event, it doesn't do anything (no error either).

DoCmd.OpenForm "F_URL", acNormal, , , , acWindowNormal
and
Set epForm = New Form_F_URL

.... both open it in full screen... I've played with settings like AutoSize,
Width (worth a try) and checked that the ShowRestore and ShowMinimize
properties are set to true. This seems like something I should remember, but,
if PopUp=false, does that mean the form has to be maximized?

The point of these windows is that settings and text-editting can be done on
multiple instances of F_URL, side-by-side, frequently switching between them.
Unfortunately, having F_URL maximized is an even bigger problem than the
Activate event not firing!

Is it the case that (therefore!) the Activate event only fires for
maximized/non-PopUp windows?

Test users are now getting used to clicking a "Set Focus" command
(Cmd_DoActivate) button manually after switching between windows... on some
of the most-frequently used text fields in F_URL, I have implemented code in
OnChange that manually fires .Activate to help in times when the user doesn't
click Cmd_DoActivate... I could *also* do a timer that runs every 2 seconds
or something to capture Screen.ActiveForm, and pretty much bypass the need to
get the Activate event working.

 

[Dirk Goldgar]

YES, that is it!!! When I set PopUp to false in design time, the Activate
event then fires.

But when PopUp is false the form always opens Maximized. There are no
Minimize or Restore buttons, and, if I stick DoCmd.Restore in the Activate
event, it doesn't do anything (no error either).

Are you sure you aren't just seeing the form opened in tabbed document mode?
Access 2007 introduced a new default mode for displaying document windows,
"Tabbed Documents". In this mode, all non-popup forms and report previews
are displayed more or less maximized in the application window, with tabs at
the top to enable you to switch from one document to another.

If that's what's going on, you can change the database option back to the
traditional "overlapping windows" mode, which I prefer. To change it, click
the Office button, then choose Access Options..., then the Current Database
tab, and change the "Document Window Options" setting from "Tabbed
Documents" to "Overlapping Windows".

Is it the case that (therefore!) the Activate event only fires for
maximized/non-PopUp windows?

Only for non-PopUp windows, but whether the form is maximized or not has
nothing to do with it.

Test users are now getting used to clicking a "Set Focus" command
(Cmd_DoActivate) button manually after switching between windows... on
some
of the most-frequently used text fields in F_URL, I have implemented code
in
OnChange that manually fires .Activate to help in times when the user
doesn't
click Cmd_DoActivate... I could *also* do a timer that runs every 2
seconds
or something to capture Screen.ActiveForm, and pretty much bypass the need
to
get the Activate event working.

I suspect that all this work is unnecessary, but will wait for your response
to my suggestion above about the document window option setting.

 

[Vexen Crabtree]

Are you sure you aren't just seeing the form opened in tabbed document mode?
Access 2007 introduced a new default mode for displaying document windows,
"Tabbed Documents". In this mode, all non-popup forms and report previews
are displayed more or less maximized in the application window, with tabs at
the top to enable you to switch from one document to another.

If that's what's going on, you can change the database option back to the
traditional "overlapping windows" mode, which I prefer. To change it, click
the Office button, then choose Access Options..., then the Current Database
tab, and change the "Document Window Options" setting from "Tabbed
Documents" to "Overlapping Windows".

Well well, you've done it again...

I think... I am completely sorted. I can now switch between open windows
MDI-style, catch the event... the user can maximize and restore F_URLs at
will, and other full-screen windows all work as normal... the only
side-effect is that form control boxes are in a different place (above the
ribbon) but that's not worth worrying about.

So... the combination was:

PopUp=false
and,
Access Options..., Current Database, Document Window Options=Overlapping
Windows

Phew!

Sincere thanks for your help!