jwcolby
jwcolby at colbyconsulting.com
Tue Jun 21 10:17:32 CDT 2011
> 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>> >