Bug 314671

Comment 1 Markus Knauer 2010-05-31 05:17:49 EDT

This is an enhancement of the initial bug description:

If one adds the setMoveable flag on the columns (i.e. columnName.setMoveable(true)), it doesn't work at all. 
In that case even a workaround such as

        table.addListener(SWT.MenuDetect, new Listener() {
            public void handleEvent(Event event) {
                Point pt = Display.getDefault().map(null, table, new Point(event.x, event.y));
                Rectangle clientArea = table.getClientArea();
                boolean header = clientArea.y <= pt.y && pt.y < (clientArea.y + table.getHeaderHeight());
                if (header) {
                    tableMenu.setVisible(false);
                    headerMenu.setLocation(event.x, event.y);
                    headerMenu.setVisible(true);
                } else {
                    headerMenu.setVisible(false);
                    tableMenu.setLocation(event.x, event.y);
                    tableMenu.setVisible(true);
                }
            }
        });

doesn't work.

Comment 2 Ivan Furnadjiev 2010-07-07 06:59:00 EDT

(In reply to comment #1)
The menu detect event is fired when right mouse button is released. In case of moveable columns, on mousedown (of both mouse buttons) setCapture is set to true and mouseup event has never reached the menu detect listener. One possible solution is to initiate the column movement only by left mouse key (this is the behavior in SWT too, at least on Windows).

Comment 3 Tim Buschtoens 2011-03-25 10:28:20 EDT

Fixed the movableColumns issue in CVS HEAD as described by Ivan. 

As for the perceived delayed reaction of the event: This is because the right-click that would open the menu has already happend (due to the use of asynchronous requests), so when the menu is added to the table there is no reason to open it. It would be complicated to fix this.

However it works in Workbench since there setVisible is alaways called after adding the menu, even though it seems to work in SWT without that. So since this easy workaround exists and is (for some reason) present in Workbench code, i propose to accept the issue and close this bug as fixed.

Comment 4 Tim Buschtoens 2011-03-30 11:57:53 EDT

Even with the workaround the code will not work as expected: Since the old menu (if it exists) will be displayed before the new one is attached and shown, both menus will be visible at the same time. Closing the old menu on setContextMenu in javascript might be one possible solution for that, though the old menu will still be visible shortly, and setVisible( true ) is still needed.

Comment 5 Tim Buschtoens 2011-03-31 06:50:30 EDT

Hiding the old menu on setContextMenu is also not an option, since the old menu might have been opened differently. To really solve this issue, we would have to create a infrastructure similar to the one we use to fill menus on menuShwon.

The menuListener could also provide a workaround: Instead of using two menus, use just one and change its content in menuShown. The mouse-location can be retrieved from the display.

Comment 6 Ivan Furnadjiev 2014-05-13 05:32:53 EDT

Still valid with RAP 2.3M3.

Comment 7 Ivan Furnadjiev 2015-03-30 09:40:39 EDT

*** Bug 463214 has been marked as a duplicate of this bug. ***