[AccessD] Call an event in another form

>
> William Benson:
> Good reminders ken. I use exactly the approach you advocate for buttonclick
> events.... most times. Declaring buttonclicked publicly and testing there
> for screen.activeform.name and screen.activeform.activecontrol.name I get
> all the control I need to centralize operations. Have to say it is a
> tradeoff in programmer friendliness. Very hard to read a longer function
> which branches to many functions amist a lot of others in a standard
> module...rather than have a proc right in the form's code module clearly
> related to on-form user interaction.
>

You're right -- it is a tradeoff. Coding professionals try to strike the
right balance for the project at hand.

But, I would like to see coders asking more questions like "Is this function
specific to the (form, object, class...), or does it belong in a public
library for shared use?"

When starting out, there's nothing wrong with peppering your forms with lots
of little functions, and then making a second pass to collect the common
functionality that emerges into standard libraries. This lets you get
something out that works, while keeping in mind a goal of standardization
and abstraction.

In fact, I think this two-pass technique can be very effective. Code the
concrete first, then abstract from that. I find it yields better results,
and probably takes less time, than building an abstract set of classes from
scratch.

-Ken