[AccessD] Refreshing open forms when something changes

I forgot to mention...

Notice that I used vars as the parameters.  This allows me to pass objects as a parameter.  I could 
pass a combo box, a form, a recordset etc.  That would be the object *raising* the event passing the 
object.

I have actually found that useful on occasion.

John W. Colby
www.ColbyConsulting.com

On 6/21/2011 11:17 AM, jwcolby wrote:
>  > That actually doesn't happen too often in Windows, but the way John is doing it, that always
> happens.
>
> Not true. My form broadcasts an event. If none of the other forms which need to receive the message
> is open then nothing receives the message. My usage is precisely the same as windows. Raise an event
> when something happens and who cares who is receiving it.
>
> My code does (in this case) use a single "channel" for all messages but that is not a requirement. I
> could quite easily have a collection of global message classes keyed on a name. Then sets of things
> could use a common "channel". In the end, there is so little message traffic that it makes no sense
> to worry about it.
>
> If you think about it, windows has several "channels". It has mouse events, keyboard events, disk
> events and so forth.
>
> I just happened to create a class which emulates an email. That was a useful model with the "from,
> To, Subject and Msg" parameters since it allowed me to easily set up filters on the messages so that
> processes could be targeted on a single "channel".
>
> Nothing says you have to use a single channel though. The nice thing about classes is that you can
> create 0 to N instances of them. ;)
>
> John W. Colby
> www.ColbyConsulting.com
>
> On 6/21/2011 9:37 AM, Jim Dettman wrote:
>>
>> Fundamentally, that's also the way Windows works. Each Window (program)
>> has a message queue. The OS and windows can send messages to the windows
>> and the windows respond to them as they see fit.
>>
>> Overall works pretty well, but it does lead to problems at times (order of
>> events) and it gets terribly inefficient when you have a large number of
>> "broadcast" messages (a message sent to all windows) and a large number of
>> windows receiving that message and trying to process it, which may or may
>> not apply to it.
>>
>> That actually doesn't happen too often in Windows, but the way John is
>> doing it, that always happens. Not too much of a problem though given the
>> limited number of forms that you might have open at one time (maybe half
>> dozen at most?).
>>
>> I might take the additional step of registering/unregistering needed
>> services as forms open or close and modify the message class to only send
>> messages to forms that need them (a Business Object), but that most likely
>> would be overkill.
>>
>> Jim.
>>
>> -----Original Message-----
>> From: accessd-bounces at databaseadvisors.com
>> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
>> Sent: Monday, June 20, 2011 08:24 PM
>> To: Access Developers discussion and problem solving
>> Subject: Re: [AccessD] Refreshing open forms when something changes
>>
>> In vb.net, this is the standard and expected way of doing things. It allows
>> the various pieces to be black boxes that do something when they receive a
>> signal. If you need another black box to do something on the same signal,
>> you sink the same event in the second black box. You don't have to change
>> the code that raises the event. It just raises it hand and waves, and any
>> black boxes that are listening do their thing. If there are no listeners,
>> the hand gets some exercise but nothing else results. Access (thank you
>> Microsoft) lets us be sloppy and not learn to use classes effectively. In
>> fact, it makes it relatively difficult to use classes except for the built
>> in object classes, and even those hide much of their inner workings.
>>
>> Charlotte Foust
>>
>> On Mon, Jun 20, 2011 at 2:38 PM, Stuart McLachlan
>> <stuart at lexacorp.com.pg>wrote:
>>
>> <<snip>>
>>