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 misinterpretation.
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.
-- -Brian http://briantrice.com