Event Recursion/Reentrancy Problem

Event Recursion/Reentrancy Problem

Post by SGFydmV » Fri, 20 Jan 2006 23:49:02


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
 
 
 

Event Recursion/Reentrancy Problem

Post by Allen Brow » Sat, 21 Jan 2006 00:22:27

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.

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

 
 
 

Event Recursion/Reentrancy Problem

Post by SGFydmV » Sat, 21 Jan 2006 00:52:03

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.
 
 
 

Event Recursion/Reentrancy Problem

Post by Allen Brow » Sat, 21 Jan 2006 00:58:17

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.
Tips for Access users - http://www.yqcomputer.com/
Reply to group, rather than allenbrowne at mvps dot org.
 
 
 

Event Recursion/Reentrancy Problem

Post by Albert D.K » Sat, 21 Jan 2006 09:00:13


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.yqcomputer.com/


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
XXXX@XXXXX.COM
http://www.yqcomputer.com/
 
 
 

Event Recursion/Reentrancy Problem

Post by Rob Oldfie » Sat, 21 Jan 2006 09:16:13

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






(some
encourage
3
menu
he
form
use
 
 
 

Event Recursion/Reentrancy Problem

Post by SGFydmV » Wed, 25 Jan 2006 22:06:02

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.
 
 
 

Event Recursion/Reentrancy Problem

Post by Albert D.K » Thu, 26 Jan 2006 02:58:31


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....


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
XXXX@XXXXX.COM
http://www.yqcomputer.com/
 
 
 

Event Recursion/Reentrancy Problem

Post by SGFydmV » Thu, 26 Jan 2006 03:25:34

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.
 
 
 

Event Recursion/Reentrancy Problem

Post by Albert D.K » Thu, 26 Jan 2006 12:47:28


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.yqcomputer.com/

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
XXXX@XXXXX.COM
http://www.yqcomputer.com/
 
 
 

Event Recursion/Reentrancy Problem

Post by SGFydmV » Sat, 04 Feb 2006 00:30:50

hank 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" wrote:

 
 
 

Event Recursion/Reentrancy Problem

Post by Albert D.K » Sat, 04 Feb 2006 02:12:02

>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.yqcomputer.com/

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

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
XXXX@XXXXX.COM
http://www.yqcomputer.com/