[DUG] Discussion & Donation

[kaller at ihug.co.nz]

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]