Robert,

>
> I am not sure I see the two issues with your posted code, other than an
> assumption that #setProperty:toValue: returns the value, like all good
> Dictionary insertion protocols.

#setProperty:toValue: is a bad dog ;-)

The second issue is the check:

actionMap := self valueOfProperty: #myEvents

in the original, before setting the actionMap to live in the property named:
#actionMap.

That's where I got confused. I didn't look far enough into the code to see
if #myEvents was some magical incantation, but it didn't seem likely.

Without a fix to this method, Morphs can't use this framework. Could you
package up a corrected fix (handling the #myEvents and #setProperty:toValue
issues) and send it to the list so that everyone is working off the same
one?

Thanks,

Jim

PS: It's just frustrating sometimes when things get killed, exasperated this
time by the fact that my stuff didn't work with the module stuff either. Too
many variables to solve at once. I think in the future a better way to
handle changes to things in the base image is to post a "grave marker" that
informs that the protocol has been deprecated upon invocation (even better
if the new protocol is mentioned). A release later, the deprecated protocol
can be removed. Thanks for your work on the new framework!!!



> Hi Jim,
>
> I think your use of this framework is the first indication I have had of
> someone using this framework in Squeak, aside from a single user in the
core
> (World enter/leave).  I think that's great!  It really is a more effective
> way to wire components together in the Observer pattern.  It's more finely
> grained to action/response.  If anyone else uses this mechanism, let this
be
> the heads up.  This framework has changed in 3.3alpha.  The changesets
were
> posted independently to the list, if anyone wants to test their code in
3.2.
> Hmm, I don't seem to have a link handy.
>
> I suppose that it was pretty aggressively changed and without notification
> to the squeak list, beyond the changeset listing.  It comes from
changesets
> to move the multicast event framework to the NuBlu book code.  As Ned
> mentioned, the new publish protocol is #triggerEvent: and friends, and the
> other big change is in the removal protocol.  Registration has not changed
> it's interface, for the most part.
>
> I am not sure I see the two issues with your posted code, other than an
> assumption that #setProperty:toValue: returns the value, like all good
> Dictionary insertion protocols.  That said, I like your implementation
> better.
>
> Sorry for any trouble this caused you and I hope you like the new protocol
> as well as you did the last one.  It was my insistence that got this code
> into the update stream.
>
> Rob
>
> > -----Original Message-----
> > From: Jim Benson [mailto:jb at speed.net]
> > Sent: Monday, March 18, 2002 12:10 PM
> > To: Squeak
> > Subject: [BUG]Morph>>updateableActionMap
> >
> >
> > Hi,
> >
> > On my pilgrimage to 3.3 land for conversion, I noticed that one of my
> > friends (#trigger:) had been murdered. Not even a grave
> > marker. Deprecation
> > isn't pretty around here.
> >
> > Trying to move forward with my life, I tried to manage as
> > best I could until
> > I ran into:
> >
> > Morph>>updateableActionMap
> >
> >  | actionMap |
> >  actionMap := self valueOfProperty: #myEvents.
> >  ^actionMap == nil
> >         ifTrue: [self setProperty: #actionMap toValue: self
> > createActionMap]
> >         ifFalse: [actionMap]
> >
> > While I can think of what a tentative fix would be, there are
> > at least two
> > bugs here and need "someone in the know" to come up with a
> > proper solution.
> > I would think it would be along the lines of:
> >
> > updateableActionMap
> > | actionMap |
> >     ^ self valueOfProperty: #actionMap
> >         ifAbsent: [ actionMap := self setProperty: #actionMap
> > toValue: self
> > createActionMap.
> >             actionMap].
> >
> >
> > But I might be missing something. The #myEvents property
> > check threw me off.
> >
> > Thanks,
> >
> > Jim
> >
> >
>
>