Eclipse Community Forums: NatTable » Adding SWT DragSource support without breaking NatTable DragMode?

Home » Eclipse Projects » NatTable » Adding SWT DragSource support without breaking NatTable DragMode?(Is it possible to support both the DnD operations built into NatTable (ColumnReorder, ColumnResize, etc) while also adding SWT DnD support for data entering/exiting the NatTable Canvas?)

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

Adding SWT DragSource support without breaking NatTable DragMode? [message #1360962]

Sat, 17 May 2014 01:53

Rob Sigel

Messages: 4
Registered: April 2014

Junior Member

I recently tried adding SWT DragSource support to the NatTable using a custom DragSourceListener which is populated by callbacks to a ...nattable.selection.RowSelectionProvider. I then called NatTable#addDragSupport() to connect things in what appears to be the "official" way. (At least it's the way things are set up in the _781_DragAndDropExample.)

This mostly worked, and I was able to drag data to other SWT and JFace widgets without problems.

Unfortunately, this also appears to break almost all other NatTable operations based upon Drag-and-drop, including column reordering and column resizing.

The only in-NatTable DnD operation that still appears to work as expected is selecting multiple rows. (I'm using a RowSelectionModel.)

If I comment out the call to NatTable#addDragSupport() then the in-NatTable DnD operations all work correctly again. (But my own DnD to other widgets does not work, of course.)

Am I doing something wrong, or is there a bug in how the tiny DragSourceListener wrapper instantiated in addDragSupport() interacts with the rest of the NatTable DnD system?

Would it make more sense for the wrapper to switch the NatTable mode as a final step in dragFinished(), instead of as the first step in dragStart()?

When I tried first tried resizing a column width in the _781_DragAndDropExample, that threw an exception and hung the application, requiring a hard kill.

Altering the DragAndDropSupport inner class in _781_DragAndDropExample so dragStart verifies there's data to be dragged will fix the hang:

    public void dragStart(DragSourceEvent event) {
        if (this.selectionLayer.getSelectionModel().getSelectedRowCount() == 0) {
            event.doit = false;
        }
    }

This will also allow everyone else to test the column header drags that are causing me problems.

In my own code, I tried adding a DragSource and listener directly to the NatTable instance myself, without calling NatTable#addDragSupport(), to avoid the unwanted wrapper behavior. In this case, the column header DnD behavior worked as expected, and I was still able to perform my own DnD from table rows to other widgets, but the NatTable was left in some intermediate drag mode state, and had apparently not detected the dragFinished/mouseUp (which happened in another widget). My symptom of this was how the cell/row table selection was still being extended to follow the mouse cursor, even though I was no longer dragging. I had to perform a mouse click in the table body to reset the selection. (This is not seen in _781_DragAndDropExample because that selectionmodel is configured to only allow single row selection. Allowing the _781_DragAndDropExample to use multiple row selection, and manually adding the DragSource instead of using NatTable#addDragSupport() will again show the same behavior I've seen in my own code.)

This again makes me wonder if the anonymous inner wrapper within NatTable#addDragSupport() should switch the NatTable mode as a final step in dragFinished(), instead of as the first step in dragStart().

(I need to mention that my table is readonly -- I'm not allowing cell editors in my table, so I can't say how those would be interacting with external DnD support.)

Is there a way for me to make this all work without modifying the NatTable source? Has anyone else already done this? I'm starting to dig deeper into the source to see how the UIBindingRegistry, the IDragModes, etc. all interact. I'm hoping to figure out a way to create and register a custom IDragMode that can limit itself to the table body and cleanly populate an SWT DragSource (using the SelectionModel) without breaking other DragModes, but a thorough explanation or a working example would make life easier. Smile

Thanks in advance for any help!

Report message to a moderator

Re: Adding SWT DragSource support without breaking NatTable DragMode? [message #1361365 is a reply to message #1360962]

Sat, 17 May 2014 06:02

Dirk Fauth

Messages: 2902
Registered: July 2012

Senior Member

Thanks for reporting.

Your suggested fix in modifying the internal DnD wrapper seems to work.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=435110

It should be fixed with the latest SNAPSHOT build 318.

Please test and comment on the ticket if this solves your issue.

As a short explanation, as NatTable is based on Canvas, we need to handle and transform all user interactions ourselves. For this all those handlers and modes are necessary. On dragging we start the drag mode, but using DnD support the mouse handling moves out of NatTable. To fix this the little wrapper was introduced. If you are not using the wrapper the issue you are describing appears, that leaves the NatTable in drag mode state.

Report message to a moderator

Re: Adding SWT DragSource support without breaking NatTable DragMode? [message #1367541 is a reply to message #1361365]

Mon, 19 May 2014 20:50

Rob Sigel

Messages: 4
Registered: April 2014

Junior Member

Thanks for the quick turnaround, Dirk!

The reported problem appears to be fixed in SNAPSHOT build 318, and I've commented the bug to confirm this.

NOTE: If users wish to further constrain their custom DragSourceEvent handler to just those events starting in the BODY region of the widget, they can further alter their own listener's dragStart to be the following (continuing the use of _781_DragAndDropExample) :

    public void dragStart(DragSourceEvent event) {
        if (this.selectionLayer.getSelectionModel().getSelectedRowCount() == 0) {
            event.doit = false;
        } else if (!this.natTable.getRegionLabelsByXY(event.x, event.y).hasLabel(GridRegion.BODY)) {
            event.doit = false;
        }
    }

Report message to a moderator