Cool, popups work much better than before, thanks a lot!
I however got a DNU at some point because ActiveHand was nil at some
point. I think that you are forking in the wrong place: your code lets
the drawing of the popup be in a separate thread, while I would have
the entire process of waiting for the delay time and then drawing be
in a separate thread. Just an extra pair of  does that, see code
As far as I can analyze the code it should not produce concurrency
issues. (Although I prefer the conceptually clean solution I detailed
last week) I have played around with this for some time and it works
fine. But of course for concurrent code this is not a guarantee ...
popupView: aBlock delay: ms
"open a popup text when the mouse enter a node"
"Yeah, this method is a bit scary"
self unsubscribeForEvent: MOMouseEnter.
self unsubscribeForEvent: MOMouseLeave.
"we compute the relative position since ActiveHand return an
relativePosition := ann position - oldPosition + ActiveHand
"We check if we are in the same node, if yes, then we evaluate
(ann root notNil and: [(ann root elementAt: relativePosition) ==
ann current]) ifTrue:
[ view := MOViewRenderer new.
aBlock value: ann element model value: view.
newCanvas := MOPopup showView: view.
ann element popup: newCanvas. ] ]] fork. "note extra ] before
ifFalse: [ann element popup ifNotNilDo: [:v | v delete]. MOPopup
self subscribe: MOMouseLeave do:
[:ann | ann element popup ifNotNilDo: [:v | v delete]. MOPopup
Sorry guys, forget this code, it does not work (although theoretically
it should ;-) ). I did not reopen the mondrian view when I tested this
version, so I was still testing Alex's version. It's a pity that the
dynamism of ST & method recompilation stops when treating with
Mondrian. I'm still not used to that :-(
No time to figure the concurrency issue out in more detail though,
sorry for that ...
On 27 Jan 2010, at 11:51, Johan Fabry wrote:
> As far as I can analyze the code it should not produce concurrency
> issues. (Although I prefer the conceptually clean solution I
> detailed last week) I have played around with this for some time and
> it works fine. But of course for concurrent code this is not a
> guarantee ...