Odd Tree Behaviour [message #461178] |
Mon, 19 September 2005 12:42 |
Eclipse User |
|
|
|
Originally posted by: kent.generatescape.com
I have a large tree and some of the nodes have the same names, albeit in
different areas in the tree.
When I go to one of these like-named nodes and try to open it, if both of
the like-named nodes are visible, it sometimes opens the wrong one, ie the
other like named one.
Does anyone have a solution for this problem?
I played around with the hash setting but that had no effect.
|
|
|
|
Re: Odd Tree Behaviour [message #461207 is a reply to message #461178] |
Mon, 19 September 2005 14:20 |
Eclipse User |
|
|
|
Originally posted by: sunil_kamath.nohotspammail.com
"kent" <kent@generatescape.com> wrote in message
news:dgm83v$un1$1@news.eclipse.org...
>I have a large tree and some of the nodes have the same names, albeit in
>different areas in the tree.
>
> When I go to one of these like-named nodes and try to open it, if both of
> the like-named nodes are visible, it sometimes opens the wrong one, ie the
> other like named one.
>
> Does anyone have a solution for this problem?
>
> I played around with the hash setting but that had no effect.
>
Are you using a TreeViewer?
If so, is your content provider correctly distinguishing between like-named
nodes?
---
Sunil
|
|
|
Re: Odd Tree Behaviour [message #461213 is a reply to message #461205] |
Mon, 19 September 2005 15:56 |
Eclipse User |
|
|
|
Originally posted by: kent.generatescape.com
sorry I have had a real problem isolating this problem in my code. I have
not had the chance to try and reproduce this with a simple example, like one
of the snippets, I was going to see first if anyone has had this problem.
What I do know is that this does not happen when I use the little plus sign,
only when I click on the item, leading me to believe the problem is where i
have indicated below,. HERE IS PROBABLY THE PROBLEM.
Another interesting side effect is when i go and hide the one which is
incorrectly openning, then the lone one will not even open.
private void makeTreeViewActions()
{
doubleClickAction = new Action()
{
public void run()
{
final TreeItem item = tree.getSelection()[0];
NewCanalNode ncn = (NewCanalNode) item.getData();
if (SOMEOTHER CASE)
{
}
else
{
// HERE IS PROBABLY THE PROBLEM
boolean expandedState = treeViewer.getExpandedState(item.getData());
if (expandedState)
{
treeViewer.collapseToLevel(item.getData(), 1);
return;
}
treeViewer.expandToLevel(item.getData(), 1);
}
}
};
"Veronika Irvine" <veronika_irvine@oti.com> wrote in message
news:dgmgfq$c0l$1@news.eclipse.org...
> Can you give a code example? How are you trying to open the node? What
> platform are you running on and what version of eclipse are you using?
>
> "kent" <kent@generatescape.com> wrote in message
> news:dgm83v$un1$1@news.eclipse.org...
>>I have a large tree and some of the nodes have the same names, albeit in
>>different areas in the tree.
>>
>> When I go to one of these like-named nodes and try to open it, if both of
>> the like-named nodes are visible, it sometimes opens the wrong one, ie
>> the other like named one.
>>
>> Does anyone have a solution for this problem?
>>
>> I played around with the hash setting but that had no effect.
>>
>
>
|
|
|
Re: Odd Tree Behaviour [message #461711 is a reply to message #461213] |
Wed, 28 September 2005 00:16 |
Eclipse User |
|
|
|
Originally posted by: kent.generatescape.com
i am still looking for a solution for this problem, I have an idea but it
requires subclassing the treeviewer in order to use some protected methods.
ie, fireTreeCollapsed and fireTreeExpanded.
The idea is basically to replace:
> // HERE IS PROBABLY THE PROBLEM
> boolean expandedState =
> treeViewer.getExpandedState(item.getData());
> if (expandedState)
> {
> treeViewer.collapseToLevel(item.getData(), 1);
> return;
> }
> treeViewer.expandToLevel(item.getData(), 1);
by firing either fireTreeCollapsed or fireTreeExpanded event.
But I wonder if this work and if so, what sort of problems will i get if I
subclass it.
All I know is that I have to override the checkSubclass() method to do
nothing.
"kent" <kent@generatescape.com> wrote in message
news:dgmjfp$gp1$1@news.eclipse.org...
> sorry I have had a real problem isolating this problem in my code. I have
> not had the chance to try and reproduce this with a simple example, like
> one of the snippets, I was going to see first if anyone has had this
> problem.
>
> What I do know is that this does not happen when I use the little plus
> sign, only when I click on the item, leading me to believe the problem is
> where i have indicated below,. HERE IS PROBABLY THE PROBLEM.
>
> Another interesting side effect is when i go and hide the one which is
> incorrectly openning, then the lone one will not even open.
> private void makeTreeViewActions()
> {
>
> doubleClickAction = new Action()
> {
>
> public void run()
> {
>
> final TreeItem item = tree.getSelection()[0];
> NewCanalNode ncn = (NewCanalNode) item.getData();
>
> if (SOMEOTHER CASE)
> {
>
> }
> else
> {
> // HERE IS PROBABLY THE PROBLEM
> boolean expandedState =
> treeViewer.getExpandedState(item.getData());
> if (expandedState)
> {
> treeViewer.collapseToLevel(item.getData(), 1);
> return;
> }
> treeViewer.expandToLevel(item.getData(), 1);
> }
> }
>
> };
>
> "Veronika Irvine" <veronika_irvine@oti.com> wrote in message
> news:dgmgfq$c0l$1@news.eclipse.org...
>> Can you give a code example? How are you trying to open the node? What
>> platform are you running on and what version of eclipse are you using?
>>
>> "kent" <kent@generatescape.com> wrote in message
>> news:dgm83v$un1$1@news.eclipse.org...
>>>I have a large tree and some of the nodes have the same names, albeit in
>>>different areas in the tree.
>>>
>>> When I go to one of these like-named nodes and try to open it, if both
>>> of the like-named nodes are visible, it sometimes opens the wrong one,
>>> ie the other like named one.
>>>
>>> Does anyone have a solution for this problem?
>>>
>>> I played around with the hash setting but that had no effect.
>>>
>>
>>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03410 seconds