[DUG] Discussion & Donation

[Kyley Harris]

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: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz]
On Behalf Of kaller at ihug.co.nz
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
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
>
> [Attachment: NotifierExample.zip]
_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi