SMLoaderPlus and ToolBuilder (was Re: SqueakMap Package Loader
water at tunes.org
Sat Dec 2 00:32:46 UTC 2006
The error turned out to be that the tree participates in the change-
update mechanism which causes infinite recursion. To wit:
- Calling #selectedItem: in the model tells the tree that
#selectedItemPath has updated
- The tree updates its path and then *by design* sends #selectedItem:
to the model
In order to avoid a deadlock, a ~~ test in #selectedItem: on the new-
and-old values guards against further change-notification.
I am unsure what better pattern to use, since none of the other
ToolBuilder-using tools uses another widget to update their trees.
Perhaps it is a bug?
In any case, I'll release my fixes shortly.
On Nov 24, 2006, at 4:42 PM, Brian Rice wrote:
> Unfortunately, after making this refactoring, I still have the same
> problem. I'll elaborate:
> - I removed any uses of ItemWrappers.
> - I changed the #selectedItemWrapperPath to #selectedItemPath,
> returning an Array of the same labels used to build the tree to
> begin with.
> - There was a variation in terms of bolding some strings, making
> them Texts, but removing this variation did not change the outcome
> (requiring a user-halt).
> What I'm reading implicitly is that the path needs to be a sequence
> of the keys used to drill down to the item. That it is not the
> sequence of objects themselves stored with those keys. It seems to
> bear out with the usage, but maybe I'm way off base for reasons of
> When I call "self changed: #selectedItemPath", I get a lock-up
> which I have to halt which puts me in a stack with
> PluggableTreeMorph>>update: (on #selectedItemPath) and
> Array>>at:ifAbsent: at the top.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061201/71f97511/PGP.pgp
More information about the Squeak-dev