Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Standard Widget Toolkit (SWT) » [Tree] unwanted automatic SelectionEvents
[Tree] unwanted automatic SelectionEvents [message #637713] Mon, 08 November 2010 14:07 Go to next message
Bogdan B. is currently offline Bogdan B.Friend
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?)
Re: [Tree] unwanted automatic SelectionEvents [message #638397 is a reply to message #637713] Thu, 11 November 2010 07:57 Go to previous messageGo to next message
Bogdan B. is currently offline Bogdan B.Friend
Messages: 50
Registered: July 2009
Member
Nobody? Not even an idea?
Re: [Tree] unwanted automatic SelectionEvents [message #638734 is a reply to message #638397] Fri, 12 November 2010 11:45 Go to previous messageGo to next message
Daniel Krügler is currently offline Daniel KrüglerFriend
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
Re: [Tree] unwanted automatic SelectionEvents [message #638738 is a reply to message #638734] Fri, 12 November 2010 12:10 Go to previous messageGo to next message
Bogdan B. is currently offline Bogdan B.Friend
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

Re: [Tree] unwanted automatic SelectionEvents [message #638784 is a reply to message #638738] Fri, 12 November 2010 15:05 Go to previous messageGo to next message
Grant Gayed is currently offline Grant GayedFriend
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
>
>
Re: [Tree] unwanted automatic SelectionEvents [message #638850 is a reply to message #638734] Fri, 12 November 2010 18:40 Go to previous messageGo to next message
Arun Kumar Simhadri is currently offline Arun Kumar SimhadriFriend
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
Re: [Tree] unwanted automatic SelectionEvents [message #638856 is a reply to message #638850] Fri, 12 November 2010 19:03 Go to previous messageGo to next message
Bogdan B. is currently offline Bogdan B.Friend
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!
Re: [Tree] unwanted automatic SelectionEvents [message #638860 is a reply to message #638784] Fri, 12 November 2010 19:26 Go to previous message
Bogdan B. is currently offline Bogdan B.Friend
Messages: 50
Registered: July 2009
Member
Grant Gayed wrote on Fri, 12 November 2010 10:05
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

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:
  


Current Time: Fri Dec 13 00:45:08 GMT 2019

Powered by FUDForum. Page generated in 0.02420 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top