My bad, just read the comment, it sounded to me like resetOpened just
closed all open nodes in tree.
It doesn't sound like expandFound contract the other nodes , if you
still need that, a
contractFully: (self indexOf: root)
send prior to expandFound: might be a proper alternative.
If you want to avoid flickering (ie. unneccessary invalidates) in the
GUI when using compound operations like that, you probably also need to
remove the view from model dependents while carrying out all but the
last operation.
Cheers,
Henry
Richard Wettel wrote:
> Hi Henry,
>
> The expandFound: works well, however without the resetOpened, which
> removes the list of elements from the tree view. As for the scrolling,
> I do not need it anymore because expandFound: also scrolls to the
> object it expands.
>
> Thanks again,
> Richard Wettel
>
> On Jan 26, 2009, at 9:59 AM, Henrik Johansen wrote:
>
>> Richard Wettel wrote:
>>> Hi,
>>>
>>> I am interested in two basic operations on a TreeView, for which I did
>>> not find solutions in the GUIDevGuide:
>>>
>>> 1. Making a TreeView scroll to a given node (to the current selection,
>>> for instance).
>>>
>> The treeview is a subclass of ScrollingView.
>> Basically, you can find the bounds of the selected item and the bounds
>> of the visible tree, calculate the difference, and scroll by that
>> amount.
>> Haven't done this for a TreeView specifically, but works just fine for
>> other scrollable views.
>>
>>> 2. Expanding/contracting the tree so that only a given node is visible
>>> (and all its ancestor nodes, of course). All the other
>>> the nodes should stay contracted, to keep the size of the view
>>> manageable.
>>>
>> TreeModel >> resetOpened;
>> expandFound: aNode
>> should work I think.
>>
>>
>> Cheers,
>> Henry
>
>
>
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Locked
