"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...
By passing the form, you don't have to worry about assigning the
variable and you get the benefit of calling it for something other
than the currently active form (should you ever need to).
Yes, the above is a fair point.
I also have never trusted .ActiveForm, as it depends on events in
the UI. Passing the exact form reference seems to me to be the most
robust way of doing this, rather than depending on a 2nd-hand method
of finding out which form it is.
The above has never been a problem Remember, when you start using a LOT of
custom menu bars etc, then your code OFTEN has to rely the screen object.
Further, this approach also means that ones custom menu bars/code will
operation on any active form. And, no matter what code calls the routine..it
will work, and those calling routines don't have to care/worry about passing
the form object. (so, there is some pros/cons here!).
So, I 100% agree, for most code, I would in fact pass the form object.
However, for menu bar code..and "general" routines (that menus + tool bars
force you to write!!), then using the screen object is standard fair, and is
reliable. The end result is more general code. You do as a rule need to
pick up the screen object RIGHT AT the start of the code, since any focus
change could have disaster results. However, once you pick up the screen
object, then a focus change does not cause a problem. Ones mileage will
certainly vary on this...especially if one is not a big user of menu bars
(which I am!).
In applications built around custom menus......often the screen object is
the only reasonable approach.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com http://www.members.shaw.ca/AlbertKallal