[AccessD] Refreshing open forms when something changes

John,

>> ...I knew nothing about the IMessage interface but
>> will certainly be looking it up. It certainly looks like a
>> built-in event interface specific to messaging...

You figured this out, but to be clear for other readers, IMessage is the
name of a standard VB class that holds the skeleton methods that define a
custom IMessage interface.
IMessage is not built-in, but it is easy to define and use.

Interfaces are a 'push' model: a reference to the object is all that is
required to receive an interface call:
    Reference ==> Interface call ==> Method in implementing object

By contrast, events are more of a 'pull' model: an object must maintain a
reference to an external event-generating object to receive events
   Event generating class <== Class reference in object <== Object receiving
events

This means that there is always more setup required for an event-driven
class model than an interface-driven one.

>> This is just ass backwards from event driven
>> programming.

And very deliberately so. This is my third-generation form messaging
interface. Each successive version lost features. This one is stripped down
to bare essentials.

The first generation was an class-based, event-driven form synchronization
framework, conceptually similar to what you use. It let you generate and use
multiple instances of any form. What a gob-stobbing amount of work for a
mediocre result! It is painful to even think of that development effort.

The problems mostly center around the Access Form event model:
 * Events do not fire in a predictable order
 * Attempting to debug events can change the order in which they fire
 * Controlling classes can't hook the Form_Load or Form_Open events when the
form is initially loaded, and Form_Activate is unreliable, making
initialization problematic.
 * Terminating a form instance when there are foreign class instances
holding references to it becomes tricky. You can easily crash Access if you
don't do it right.
 * Managing Modal forms becomes problematic - you have to unset the Modal
property of all open modal forms to show a new modal form

Contrast this with IMessage:
 * No persistent reference to an open form is maintained. Forms open, live
and die with no complications
 * You can send an initialization message to a form without regard for where
it is in its startup event cycle
 * Modality is handled in the normal way by Access

My first-generation solution has 5 classes and one module (it really needs
at least one more class). Every parent form needs to maintain it's own
sender object reference, and every child form has to maintain a listener
object.

The IMessage solution has one dirt-simple interface class and one function.
Setting up forms for IMessage is stupid-simple: just implement one method.

>> ...So frm_AfterUpdate would have to have a line in
>> it for every "destination" of the message
>>    (I edited your example for clarity)
>> sub form_AfterUpdate
>>    SendMessageToForm "FrmA", "ParentUpdate"
>>    SendMessageToForm "FrmK", "ParentUpdate"
>>    SendMessageToForm "FrmZ", "ParentUpdate"
>> end sub

Yes -- and isn't that wonderfully direct, easy-to-follow code! You can tell
who gets notified without any run-time debugging, or rummaging around for
the setup code.

Most Access applications have only a few dozen forms. Any one parent form
typically interacts with a handful of children. In this specific case, I
think a completely abstract, handle-anything framework is overkill for the
typical app. Some pragmatic, limiting assumptions can dramatically simplify
code, with almost no effect on function.

>> ...This certainly works but it runs all of that code
>> about checking to see if the form is open etc,
>> parsing events, all that stuff...

Again, IMessage is designed to not maintain persistent references to open
forms. The resulting slight overhead of an IMessage call is well worth the
problems it avoids.

>> In any event, I simply do not care what form is
>> open, nor do I have to go discover what form is
>> open, nor do I have to generate lists of what
>> form I think might be open in the place that
>> raises the event.

It would be fairly easy to build IMessage-based subscriptions, where forms
add themselfs to a specific notification list, and get all messages a parent
sends along that 'channel'.

>> Event Driven Programming, available now at a
>> programming kiosk near you.  :)

I haven't used .NET, but hopefully it has a much more stable, reliable and
predictable form event model than Access does. If that is the case, I would
have much more enthusiasm for an event-based form messaging approach in .NET
than I do in Access.

-Ken