Eclipse Community Forums: Standard Widget Toolkit (SWT) » [Tree] unwanted automatic SelectionEvents

Help

Home

Home » Eclipse Projects » Standard Widget Toolkit (SWT) » [Tree] unwanted automatic SelectionEvents

Show: Today's Messages :: Show Polls :: Message Navigator

[Tree] unwanted automatic SelectionEvents [message #637713]

Mon, 08 November 2010 14:07

Bogdan B.

Messages: 50
Registered: July 2009

Member

I have a Tree constructed with the following style:

SWT.SINGLE | SWT.CHECK | SWT.BORDER | SWT.H_SCROLL | SWT.V_SCROLL
                | SWT.FULL_SELECTION | SWT.VIRTUAL

and I added a SelectionListener on it.
I am working with an Eclipse 3.4.2 target on a 32bit WinXP.

The problem is that I get automatic SelectionEvents when I for example remove a selected (blue background) row in the tree calling MyTreeViewer.remove(Object). Looking deeper into the stack trace, I see that the event is constructed and scheduled by Tree.wmNotifyChild() for the cases:
case OS.TVN_SELCHANGEDA:
case OS.TVN_SELCHANGEDW:

The problem is that I cannot differentiate between those "automatic" events and the "real" selection events the user fired by clicking with the mouse or navigating with the keyboard in the Tree. And I just want to react only to those explicit "user"-fired selection events.

Is there a way to turn off those "automatic" events? Or to differentiate between them?
(like implementing a Strategy or something?)

Report message to a moderator

Re: [Tree] unwanted automatic SelectionEvents [message #638397 is a reply to message #637713]

Thu, 11 November 2010 07:57

Bogdan B.

Messages: 50
Registered: July 2009

Member

Nobody? Not even an idea?

Report message to a moderator

Re: [Tree] unwanted automatic SelectionEvents [message #638734 is a reply to message #638397]

Fri, 12 November 2010 11:45

Daniel KrÃ¼gler

Messages: 853
Registered: July 2009

Senior Member

On 11.11.2010 08:57, Bogdan B. wrote:
> Nobody? Not even an idea?

I cannot find your original message and your follow-up does not provide
enough information to reproduce the problem.

- Daniel

Report message to a moderator

Re: [Tree] unwanted automatic SelectionEvents [message #638738 is a reply to message #638734]

Fri, 12 November 2010 12:10

Bogdan B.

Messages: 50
Registered: July 2009

Member

Hi, Daniel! here it is:
http://www.eclipse.org/forums/index.php?t=msg&S=47603403 915d9a0e02e40e602d01317d&th=199829&goto=637713#msg_6 37713

Daniel KrÃ¼gler wrote on Fri, 12 November 2010 06:45

On 11.11.2010 08:57, Bogdan B. wrote:
> Nobody? Not even an idea?

I cannot find your original message and your follow-up does not provide
enough information to reproduce the problem.

- Daniel

Report message to a moderator

Re: [Tree] unwanted automatic SelectionEvents [message #638784 is a reply to message #638738]

Fri, 12 November 2010 15:05

Grant Gayed

Messages: 2150
Registered: July 2009

Senior Member

Hi, sorry for the late reply,

There isn't a way to differentiate between these cases by looking at the
event. This is one of those rare cases where an event gets sent for a
programmatic change, because the selection change could be a side effect of
doing something different (eg.- disposing a TreeItem that has selected child
items). I think the only way to handle this in your case is to set a
boolean flag around your call to remove() that indicates that selection
change events received are a result of the remove() call. I know this is a
bit ugly, but I don't think there's another option (this is why most
programmatic changes do not cause events to be sent).

Grant

"Bogdan B." <bbarzu@gmail.com> wrote in message
news:ibjak2$t4v$1@news.eclipse.org...
> Hi, Daniel! here it is:
> http://www.eclipse.org/forums/index.php?t=msg&S=47603403 915d9a0e02e40e602d01317d&th=199829&goto=637713#msg_6 37713
>
> Daniel Krügler wrote on Fri, 12 November 2010 06:45
>> On 11.11.2010 08:57, Bogdan B. wrote:
>> > Nobody? Not even an idea?
>>
>> I cannot find your original message and your follow-up does not provide
>> enough information to reproduce the problem.
>>
>> - Daniel
>
>

Report message to a moderator

Re: [Tree] unwanted automatic SelectionEvents [message #638850 is a reply to message #638734]

Fri, 12 November 2010 18:40

Arun Kumar Simhadri

Messages: 5
Registered: November 2010
Location: Cedar Rapids

Junior Member

If you doesn't want the tree control to fire selection changed event when you are removing some rows from the tree, try removing the selection changed listener that you attached to it and add it again after the row is removed.

For Example:

removeRow(){

viewer.removeSelectionChangedListener(listener);
//////////////////////

// Code for removing the row
///////////////////////
viewer.addSelectionChangedListener(listener);

}

Hope this helps

Report message to a moderator

Re: [Tree] unwanted automatic SelectionEvents [message #638856 is a reply to message #638850]

Fri, 12 November 2010 19:03

Bogdan B.

Messages: 50
Registered: July 2009

Member

That would only work if the TreeViewer.remove() does NOT ONLY schedules the event but also notifies the listeners. If the notification of the listeners take place later, after remove() completes, than removing and adding the listener as you suggested would have no effect.

But, of course, I shall try this on Monday and post the result. Thank you!

Report message to a moderator

Re: [Tree] unwanted automatic SelectionEvents [message #638860 is a reply to message #638784]

Fri, 12 November 2010 19:26

Bogdan B.

Messages: 50
Registered: July 2009

Member

Grant Gayed wrote on Fri, 12 November 2010 10:05

My use case is a bit more complicated than that:
I reimplemented the PostSelection behaviour because it is not supported (yet) by Eclipse RAP. I mention that I develop a single sourced application which has a rich client version (Eclipse RCP) and a web version (RAP). By PostSelection behaviour I mean that I only schedule my selection actions when the SelectionListener is notified, and after a certain delay I run them or ignore them if other selection events were fired in the meantime (use case: changing selection quickly with the keyboard arrow up/down should only perform the action for the last row I stopped on and ignore the others).
And I am not quite sure that I shall be able to cleanly sync that with your semaphore solution.

I already thought of a semaphore myself, but more precise than a boolean flag:
to record the timestamps before and after .remove() and ignore the events scheduled during this time. But I found 2 problems to this approach:
1) event.time is not supported in Eclipse RAP
2) Even in RCP, I have no idea what the value of event.time is. It's not the number of millis from 1.1.1970, like all other Java dates are. The value is given by Display.getlastEventTime(), which seems to be platform specific:

int getLastEventTime () {
    return OS.IsWinCE ? OS.GetTickCount () : OS.GetMessageTime ();
}

Any Idea of how could I transform that into a Java date?

[Updated on: Fri, 12 November 2010 19:28]

Report message to a moderator

Previous Topic:	Getting checkbox state from a table
Next Topic:	StyledText Does Not Show Control Characters

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 08:09:23 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter