Event Recursion/Reentrancy Problem

[Harvey]

Hello:

I have recently moved event calls from buttons on forms in a tab control to
menus using the CommandBarMenu/CommandBarControl object model. It works with
the exception that about 1/2 the items will cause the code to execute 3
times, independent of what is inside the method being called or the name of
the method (even when simplified to a simple msgbox call). It may be
relevant that the form contains a Tab Control having 3 tabs.

Can someone please help? thank you in advance.

Harvey

 

[Allen Browne]

Harvey, did you put a function name in the action for the command bars?

My experience is that Access handles command bars correctly if you use a
macro, but not if you use a function name. The actual problems seem to vary
between versions, but AFAIK, the macro call should work correctly in any
version.

So, try creating a macro. Use the Macro Name column to handle all the items
you need for your command bars. In each case, use the RunCode action to call
your function.

 

[Harvey]

Hi Allen.

thank you for the quick response. The OnAction= of all of my items (some of
which work fine, others which are recursive 3 times) looks like:

Forms![Grant Information Access].frmGDVsub.Form.mysub

where mysub is a function. This function is in a subform which is located
on a page (pgResults) of a 3-tabbed Tab Control (i.e., frmGDVsub is the
"Source Object" property of pgResults). Do you think that the event is
somehow bubbling through the 3 tabs, thus causing the 3 executions? Would a
syntax like:

Forms![Grant Information Access].pgResults.frmGDVsub.Form.mysub

be the correct syntax?

thanks again for any help you can offer.

 

[Allen Browne]

While I cannot be certain, I think the 3 tabs vs 3 executions is just
coincidence.

My experience has always been with code in a standard module (not the module
of a form), and setting the action to a macro name (not a function name)
solved my issues.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.

Reply to group, rather than allenbrowne at mvps dot org.

Hi Allen.

thank you for the quick response. The OnAction= of all of my items (some
of
which work fine, others which are recursive 3 times) looks like:

Forms![Grant Information Access].frmGDVsub.Form.mysub

where mysub is a function. This function is in a subform which is located
on a page (pgResults) of a 3-tabbed Tab Control (i.e., frmGDVsub is the
"Source Object" property of pgResults). Do you think that the event is
somehow bubbling through the 3 tabs, thus causing the 3 executions? Would
a
syntax like:

Forms![Grant Information Access].pgResults.frmGDVsub.Form.mysub

be the correct syntax?

thanks again for any help you can offer.

Harvey, did you put a function name in the action for the command bars?

My experience is that Access handles command bars correctly if you use a
macro, but not if you use a function name. The actual problems seem to
vary
between versions, but AFAIK, the macro call should work correctly in any
version.

So, try creating a macro. Use the Macro Name column to handle all the
items
you need for your command bars. In each case, use the RunCode action to
call
your function.

 

[Albert D.Kallal]

Hi Allen.

thank you for the quick response. The OnAction= of all of my items (some
of
which work fine, others which are recursive 3 times) looks like:

Forms![Grant Information Access].frmGDVsub.Form.mysub

It is known bug...and has existed since a97...possibility earlier.

I have no trouble using functions in the menu bars..and I actually encourage
you to use this feature..

the trick is to NOT use the forms qualifier....

So, in the above, you must use:

=MySubToCall()

However, in your example, you are trying to execute a routine in a sub
form.

I would suggest that you put a public function in the main form that calls
the Sub For you

eg, in form [Grant Informaton Access], you would go

Public Function MySubToCall

me.frmGDVsub.Form.MySub

End Function

Remember, DO NOT USE the full forms qualifier...if you do..it gets called 3
times.

note that this is a real bonus feature, since then you can use the SAME menu
bar for different forms. the menu bar will call the public function into he
FORM THAT HAS the focus. Further, if no public function is found in the form
with the focus, then he standard code modules are then searched...which is
also an great feature..since if you DO NOT add the public function to the
form, then you GENERAL CATCH all function is written. When you start to use
this...you will find it a VERY nice feature of ms-access.

So, sure...continue to use the function names directly into he menu bars,
but always use

=MyFunctionName()

Note that you also pass parameters in the () part if you need.

And, here is the bug article note on the above...

http://www.mvps.org/access/bugs/bugs0048.htm

 

[Rob Oldfield]

Though it does open the entire "that's not a bug, it's a feature" debate...

Hi Allen.

thank you for the quick response. The OnAction= of all of my items (some
of
which work fine, others which are recursive 3 times) looks like:

Forms![Grant Information Access].frmGDVsub.Form.mysub

It is known bug...and has existed since a97...possibility earlier.

I have no trouble using functions in the menu bars..and I actually encourage
you to use this feature..

the trick is to NOT use the forms qualifier....

So, in the above, you must use:

=MySubToCall()

However, in your example, you are trying to execute a routine in a sub
form.

I would suggest that you put a public function in the main form that calls
the Sub For you

eg, in form [Grant Informaton Access], you would go

Public Function MySubToCall

me.frmGDVsub.Form.MySub

End Function

Remember, DO NOT USE the full forms qualifier...if you do..it gets called 3
times.

note that this is a real bonus feature, since then you can use the SAME menu
bar for different forms. the menu bar will call the public function into he
FORM THAT HAS the focus. Further, if no public function is found in the form
with the focus, then he standard code modules are then searched...which is
also an great feature..since if you DO NOT add the public function to the
form, then you GENERAL CATCH all function is written. When you start to use
this...you will find it a VERY nice feature of ms-access.

So, sure...continue to use the function names directly into he menu bars,
but always use

=MyFunctionName()

Note that you also pass parameters in the () part if you need.

And, here is the bug article note on the above...

http://www.mvps.org/access/bugs/bugs0048.htm


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)
http://www.members.shaw.ca/AlbertKallal

 

[Harvey]

Great recommendation, thank you Albert. Thanks to both you and Allen for
bailing me out of this one - search through MS KB disclosed nothing of this
problem. Simply wrapping form event handlers in module-based methods did the
trick.

Hi Allen.

thank you for the quick response. The OnAction= of all of my items (some
of
which work fine, others which are recursive 3 times) looks like:

Forms![Grant Information Access].frmGDVsub.Form.mysub

It is known bug...and has existed since a97...possibility earlier.

I have no trouble using functions in the menu bars..and I actually encourage
you to use this feature..

the trick is to NOT use the forms qualifier....

So, in the above, you must use:

=MySubToCall()

However, in your example, you are trying to execute a routine in a sub
form.

I would suggest that you put a public function in the main form that calls
the Sub For you

eg, in form [Grant Informaton Access], you would go

Public Function MySubToCall

me.frmGDVsub.Form.MySub

End Function

Remember, DO NOT USE the full forms qualifier...if you do..it gets called 3
times.

note that this is a real bonus feature, since then you can use the SAME menu
bar for different forms. the menu bar will call the public function into he
FORM THAT HAS the focus. Further, if no public function is found in the form
with the focus, then he standard code modules are then searched...which is
also an great feature..since if you DO NOT add the public function to the
form, then you GENERAL CATCH all function is written. When you start to use
this...you will find it a VERY nice feature of ms-access.

So, sure...continue to use the function names directly into he menu bars,
but always use

=MyFunctionName()

Note that you also pass parameters in the () part if you need.

And, here is the bug article note on the above...

http://www.mvps.org/access/bugs/bugs0048.htm


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)
http://www.members.shaw.ca/AlbertKallal

 

[Albert D.Kallal]

Great recommendation, thank you Albert. Thanks to both you and Allen for
bailing me out of this one - search through MS KB disclosed nothing of
this
problem. Simply wrapping form event handlers in module-based methods did
the
trick.

As mentioned, make important notice of that you can put the function in the
form's module, OR in a standard module.

If the code written belongs to the form...them simply declare the function
as public in the form....

 

[Harvey]

Now I'm confused. this is just the problem I have been having - accessing
public methods in a Form module. That does not work. Only when I create an
envelope method in a regular, non-form module am I able to access the
original form-based routine.

 

[Albert D.Kallal]

Now I'm confused. this is just the problem I have been having - accessing
public methods in a Form module. That does not work. Only when I create
an
envelope method in a regular, non-form module am I able to access the
original form-based routine.

You simply declare the function as public in the forms module..and the menu
will use that one.

You MUST declare the function as public in the forms code for this to work.


I going to repeat my post again:

<quote>

note that this is a real bonus feature, since then you can use the SAME menu
bar for different forms. The menu bar will call the public function into he
FORM THAT HAS the focus. Further, if no public function is found in the form
with the focus, then he standard code modules are then searched...which is
also an great feature..since if you DO NOT add the public function to the
form, then you GENERAL CATCH all function is written. When you start to use
this...you will find it a VERY nice feature of ms-access.

</quote>

Note that the form MUST HAVE the focus. (else, how would ms-access know
which one to call!!!). So, you can well use a public function in the menu
bar..and it can all a public function in the form. In fact, this *is* the
best approach here. Why put code in some un-related module some where else?
If the code belongs to the particular form..then that code should be placed
in the form. It makes logical sense, and from a maintains point of view it
also makes sense.

For example, all of my forms have a public function called MyDelete().

eg:

Public Function MyDelete()

' code here to delete the record...sometimes some special checking..and
special code needs to be run...

End Function

However, for a lot forms, why write delete code over and over? So, in a main
standard code module..I ALSO HAVE a function called MyDelete(). This way, if
the form needs special delete code...I put the code in the forms module. If
the form does NOT need any code..then the general "catch all" mydelete
function in the standard code module is used. This is exactly the behavior I
would
want...

This means for ever more when I build menubars I simply assume that all my
forms will can then have a delete option in the menu bar. Further, if the
form that has the focus DOES NOT have a public function, then the standard
code modules are searched for the function!

Remember, the key here in that in the menu bar "on action", you DO NOT use
the forms! qualifier (if you do..the 3 times bug will rear its ugly head).

So, in the menu bars delete option, the on action would be set to

=MyDelete()

All in all, how this works is a ideal desing....

Here is some more screen shots of menus in ms-acces..and they all use the
above concepts..

http://www.members.shaw.ca/AlbertKallal/Articles/UseAbility/UserFriendly.htm

 

[Harvey]

Thank you, but this has not been my experience. Obviously it must be public
to be accessible from either a form or a module. but when thus declared in
the form is exactly and reproducibly, for any function, when I get the
execute 3 times problem, and this is also the finding on the MVP site and MS
kb article published earlier in this thread, I believe by Allen. So it may
be that you are using a later version of access, but thus is the case for
Access 2000.

 

[Albert D.Kallal]

I get the
execute 3 times problem,

The above problem does NOT occur if you read my post and how to avoid the
problem.

Check the following article (written my me....).

http://www.mvps.org/access/bugs/bugs0048.htm

The whole point of this post..and the ensuing threads was how I clarify
explained you can avoid the 3 times bug..