[AccessD] Refreshing open forms when something changes

 > I think JC was talking about a messaging class for an example of using events, not as his end all 
be all of using events.

Precisely.  In fact several things come into play here.

1) Only forms that grab a pointer to clsMsg and sink the events actually get the message (have to 
process it).

2) I can if I wish create 1 to N (hundreds if I wish) different instances of clsMsg and each 
"functional set" can grab a pointer to the clsMsg instance that it needs to watch messages on.

3) Most forms just "sit there" anyway.  The user is looking at the screen, yaking on the phone, 
smoking a cigarette and oh yea, entering stuff.

Processing a message is going to take about... under a millisecond.  Probably a few hundred 
microseconds in fact.  So even if I have a dozen forms open at once, and all of them use the message 
channel, how much machine time is actually used to process the message in all the forms?

 > I think JC was talking about a messaging class for an example of using events, not as his end all 
be all of using events.

In my framework I have dozens of classes and they sink literally hundreds of events.  The message 
class is nothing more than an example of using events to solve a specific common problem.  We have 
all run into this "something happens over here and the combos over there are not requeried".  I 
actually fixed this specific problem in this specific database using my clsMsg.

BTW I have been using this for about 10 years now.

 From my framework, circa 12/2001:

'--------------------------------------------------------------------------
'.Written By   : John W. Colby
'.Date Created : 12/06/2001
'.Rev. History :
'.Comments     :
'.-------------------------------------------------------------------------
'.
' ADDITIONAL NOTES:
'
'The message class implements a Withevent / RaiseEvent communications method
'that can now be generically implemented using this class as the comm object.

John W. Colby
www.ColbyConsulting.com

On 6/21/2011 12:21 PM, Drew Wutka wrote:
> Ummmmmm.... but that is only if you are creating an extremely broad and
> generic event process.
>
> In your example, of a customer being added, if I was developing a system
> I would have a 'customers' class, which had a 'New' (or changed)
> Customer event.  So only forms/windows/classes that interacted with the
> Customers class would have that event sunk, so that only those
> forms/windows/classes would do anything when that event was raised.
>
> I think JC was talking about a messaging class for an example of using
> events, not as his end all be all of using events.
>
> Drew