Nice to see someone new. That will make Richard happy. I use messaging of various kinds, this submission is just one. A Typical use of this type of notification will be something like:
A Combobox whose contents are based on a list of objects. This kind Of notification allows dynamic adjustments to the combobox contents as Items are added, or changed in the list of objects. It also means that Unlike an OnChange Event, which is locked into one listener, I can have more Than one combobox using the list, or a grid, etc. I also have a broadcast message handler, similar to the the Notifier, except that it is designed to be a general broadcaster of a message, so it is the message name that a listener registers, rather than a source of a message. That class is more useful for propagation, as your message center may do. I also find that it makes it easy for distribution of messages over sockets. For Example. My server may have a single receiver set to capture a list of broadcasted messages (SavedA, SavedB, SavedC). It can then stream those messages to a client, which rebroadcasts them and the client GUI can update itself easily. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, 11 May 2006 6:44 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Discussion & Donation Hi My first posting to this group. I am using a "message center" that works just fine, you generate (ie broadcast) messages and you register listeners to act on them. Its a bit more generic that creating specifically named events. This generic messaging model is quite lightweight, and sends a record along with every message to indicate the object responsible, and a flag to give you selectivity. I plan to use this later when my code gets more complex, in the meantime it works fine, and even allows the same object to pick up the message. Where it becomes useful is in acting on "side effects" that do not occur within an object. Instead of writing a handler to get a child form, for example, to modify something about its parent, and even to act on some sibling component, it is cleaner to have the parent form listen for the custom event and hand off to those components as the messages arrive. That way the child form does not get cluttered up with code for side effects that it is not really directly responsible for. It has a message "post" option so you can delay the actions if you want to ensure all the current processing is out of the way first. As proof of concept when an object needs saving, or no longer needs saving, I set a "NeedSave" property which generates messages as it goes on or off. These can be picked up by a toolbar for example. So I can put the toolbar code into the message center where it is at least easier to find, and anyway does not logically belong to the child window. Keith > In an attempt to create some more interesting discussion, > other than talking about the crud IDE issues, I am > donating some useful code for discussion, rather than for > help. Feel free to keep/use the code if you want to. Be > mean if you feel the need (but if your personal then watch > out ;) Hopefully this may introduce a discussion where > people learn something, or are able to contribute some > interesting ideas/information about the topic (which is > object notification and observation). > > > > In the attached zip is a sample application showing a > basic, but horrible use of the class in uNotifier.pas. > TNotifer is a class I wrote a long while back which > loosely follows an observer pattern for allowing > one-to-many observations between an object, and a bunch of > interested object. > > > > The main difference this class has between many observer > patterns is that you do not have to modify existing > classes, or sub-class anything, or instantiate anything in > your existing objects. The TNotifier handles all the > bindings, you just need to implement one listening event > on each listening object. > > > > The sample app is a corny app that makes child forms > (button click) update a memo based on changes to the memo > on the main form. God help me if I ever did anything as > potentially unthread safe as that in a real app. > > > > Fun fun fun.... (I hope the app compiles. You never know > with these tricky little sample apps) > > > > > _______________________________________________ > Delphi mailing list > [email protected] > http://ns3.123.co.nz/mailman/listinfo/delphi > > [Attachment: NotifierExample.zip] _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi
