Eclipse Community Forums: Standard Widget Toolkit (SWT)

Help

Home

Home » Eclipse Projects » Standard Widget Toolkit (SWT) » SWT maps event to wrong control

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

SWT maps event to wrong control [message #1707090]

Wed, 02 September 2015 08:39

Paras Patel

Messages: 8
Registered: September 2015

Junior Member

HI,
Initial setup:
RCP 4 is used for client rendering.
In the current part/dialog, org.eclipse.jface.viewers.TableViewer is used to display data.
When a user double clicks on any of the row in the table, new part is opened.

Problem:
The user action of double click generated two events:
1. Double click event
2. Mouse Up event

The double click event is dispatched to TableViewer which opens the new part in the same UI thread. But mouse-up event is dispatched to the control of the new part which is not desired.

Shouldn't the mouse up event be dispatched/mapped to the tableviewer?
Is there any way to flush the mouse up event?

Report message to a moderator

Re: SWT maps event to wrong control [message #1707151 is a reply to message #1707090]

Wed, 02 September 2015 15:15

Brian de Alwis

Messages: 877
Registered: January 2012

Senior Member

You could spin the display event loop before you open the part.

Display display = control.getDisplay();
while(!display.isDisposed() && display.readAndDispatch()) { /* spinning */ }

[Updated on: Wed, 02 September 2015 15:16]

Report message to a moderator

Re: SWT maps event to wrong control [message #1707643 is a reply to message #1707151]

Tue, 08 September 2015 08:59

Paras Patel

Messages: 8
Registered: September 2015

Junior Member

HI,
Thanks for the suggestion.
I tried to spin the display event loop as per your suggestion but the Mouse-up event is still called.
On debugging, I found that the mounse-up event is called because of OS.DispatchMessage.
PFA of call stack of Mouse-up event.
Is there a way to spin MSG?

Attachment: Mouse-up event call stack.png
(Size: 12.40KB, Downloaded 172 times)

Report message to a moderator

Re: SWT maps event to wrong control [message #1707700 is a reply to message #1707643]

Tue, 08 September 2015 14:46

Brian de Alwis

Messages: 877
Registered: January 2012

Senior Member

Hmm, so maybe the OS only injects the mouse-up after the double-click event returns. Does putting your part-open in an asyncExec() help? (And remove the event-spin loop.)

Report message to a moderator

Re: SWT maps event to wrong control [message #1707793 is a reply to message #1707700]

Wed, 09 September 2015 12:01

Paras Patel

Messages: 8
Registered: September 2015

Junior Member

Hi,
It didn't solved the issue.
I tried with the following:

Display.getDefault().asyncExec(new Runnable() {
public void run() {
//open new part
}
});

Report message to a moderator

Re: SWT maps event to wrong control [message #1707948 is a reply to message #1707793]

Thu, 10 September 2015 17:57

Brian de Alwis

Messages: 877
Registered: January 2012

Senior Member

Ok, last approach that I can think of: don't open your part in the double-click but in the mouseUp event. In your double-click event, set a flag that a double-click was received. To be on the safe side, I'd do something like the following (untested) code:

private Widget doubleClickedWidget = null;

...
   button.addMouseListener(new MouseListener() {
     public void mouseDown(MouseEvent e) {
         doubleClickedWidget = null;
     }
     public void mouseDoubleClick(MouseEvent e) {
       doubleClickedWidget = e.widget;
     }
     public void mouseUp(MouseEvent e) {
        // Ensure this event comes from the double-clicked widget
        if(doubleClickedWidget == e.widget) {
          // open part
        }
     }});

Report message to a moderator

Re: SWT maps event to wrong control [message #1707949 is a reply to message #1707948]

Thu, 10 September 2015 18:02

Brian de Alwis

Messages: 877
Registered: January 2012

Senior Member

Oh and if the mouseUp approach doesn't work, then use timerExec(). It seems like the mouseUp event from the mouse double-click haven't been queued when the mouseDoubleClick event is raised. It's possible other events are still pending too. Using asyncExec won't help in this case as it's handled internally. Using timerExec() with a small timeout (e.g., 5ms) should be sufficient for all follow-on events to have been generated and handled.

We have a similar problem in the CSS theming support, and I suspect we'll need to use the timerExec() approach.

Report message to a moderator

Re: SWT maps event to wrong control [message #1708142 is a reply to message #1707949]

Mon, 14 September 2015 08:28

Paras Patel

Messages: 8
Registered: September 2015

Junior Member

HI Brian de Alwis,
Thanks for the suggestions.
Let's take the suggestion one by one:
1. mouseUp approach : We also thought of similar solution. But you know if the user perform extra clicks(more than double click), then again the mouse-up event of the extra clicks is mapped to the widget in the next screen.
2. timerExec() approach: It works with the timeout of (>=200 ms).
But if the user fires extra click after 200ms(and before the new part opens), then again undesirable event will occur. I know this won't happened in 99% of the case

Solution which we implemented.
Before explaining the solution, I would like to give brief information on the sequential events that are taking place in our project design, when the new part is opened.
1. View of new part gets rendered --->UI thread
2. Server call to get the data -----> Non-UI thread
3. Populating data in the swt widgets----> UI thread but executed by asyncExec

Till 2 is in progress, we show progress bar. This progress bar is displayed using asyncExec() and that's why the undesirable event occurs first.

We did the following:
A. Disable the view in step 1-->composite.setEnabled(false)
B. Enable the view in last logical step in 3.-->composite.setEnabled(true)

In between A and B, Display gets sufficient time to dispatch undesirable events(this event will not have any effect on new part because it is disable).

And again thanks for your suggestions.
Frankly your "timerExec() approach", help us to route to the solution we implemented.
Please free feel to give your further opinions.

Report message to a moderator