Jim Dettman
jimdettman at verizon.net
Tue Jun 21 11:53:35 CDT 2011
<<Ummmmmm.... but that is only if you are creating an extremely broad and generic event process>> That's what I understood him to be doing... <<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 would agree. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Tuesday, June 21, 2011 12:21 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Refreshing open forms when something changes 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 -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Tuesday, June 21, 2011 10:48 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Refreshing open forms when something changes <<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 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI Business Sensitive material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com