[AccessD] Refreshing open forms when something changes

Jim Dettman jimdettman at verizon.net
Tue Jun 21 10:47:43 CDT 2011


<<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.>>

  That is true.  Obviously if a form is not open (or a window in Windows),
it's not going to get the message event.

  But if it is open, it receives the message whether it needs it or not.  So
if you have six forms open and I just added a customer, then all six forms
get the message "customer added - requery if you have any customer lists"
even if they don't have a customer list. And each will need to process the
message to figure out that they don't need it.

  In Windows, not all messages are of the "broadcast" type.  For example, a
mouse click; that goes to only one window. In contrast, a shutdown message
goes to all windows.

<<If you think about it, windows has several "channels".  It has mouse
events, keyboard events, disk 
events and so forth.>>

  They all end up in the same queue.

Jim.


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, June 21, 2011 11:18 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Refreshing open forms when something changes

 >   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>>
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list