Canceled drop leaves behind garbled display

[dbscott525]

SmartGWT version: 5.0-p20150628

I have implemented drag and drop of one canvas to a HLayout.

For the drop handler I immediately cancel the drop and affect the change in another way in my application.

Here is the cancel code:

    [B]private[/B] [B]void[/B] handleDropEvent(DropEvent dropEvent, AbstractTopicLayout movedTopic) {
        /**
         * This cancels the move because the move is accomplished by the code
         * below. The default move behavior of SmartGWT is not needed or wanted
         * here.
         */
        dropEvent.cancel();
       
        CgEditor.[I]moveTopic[/I](movedTopic.getAppTopic(), appTopicGroup, getDropPosition());
 
    }

For the canvas that is being dragged I have tried two settings:

            [B]if[/B] ([B][I]BUGGY_DRAG[/I][/B]) {
                setCanDragReposition([B]true[/B]);
                setCanDrop([B]true[/B]);
                setDragAppearance(DragAppearance.[B][I]TARGET[/I][/B]);
                setDragType(DragAndDropType.[B][I]RegisterTopic[/I][/B].name());
            } [B]else[/B] {
                setCanDrag([B]true[/B]);
                setCanDrop([B]true[/B]);
                setDragType(DragAndDropType.[B][I]RegisterTopic[/I][/B].name());
            }

With the first set of settings the result is that the display is garbled (attached).

With the second set of settings the drag is successful with a clear display (attached).

I’m just guessing but it appears that even though I cancel the drop the canvas being dropped is still being displayed and that it’s display is transparently overlaying the canvas in the same place.

I prefer the first set of settings because it shows the item being dragged rather than just an outline like the second settings show.

What are the correct settings to accomplish what I would like to accomplish?

[Isomorphic]

It's unclear whether this is a core problem with Layout-to-Layout drag and drop, or some kind of issue in your application (nothing is clearly wrong from the code you've showed so far, but there are lots of ways that code you haven't shown could break things).

If you like, we can spend a couple of your booked hours to try to take one of our examples and modify it to cancel the drop, with settings like yours, and see if we can replicate the effect. Let us know if this is what you'd like us to do, otherwise, the next step would be for you to try that same approach and see if you find evidence of a framework bug.

[dbscott525]

I tried various experiments include:

1. Not doing anything after the cancel. This doesn’t show the display anomaly.
2. Setting the layouts that are being replace to not visible. The display anomaly occurs.

Finally, I set the dragged layout to invisible after the cancel. This made the display anomaly go away.

So at this point our display problem is resolved. However, I’d be happy to show you the problem if you’d like to get a lead on fixing this potential bug.

The other question I have about this is that with the same drag/drop settings the cross hair cursor is displayed for an image but for a layout the finger pointing cursor is displayed.

I would like the cross hair cursor to be displayed for all drag and drop operations. Is there a way to do this?

I did try “canvas.setDragRepositionCursor(Cursor.CROSSHAIR);” but that had no effect on the layout canvas.

Finally, has the documentation moved? This link https://www.smartclient.com/smartgwt...t/HLayout.html gets a 404 error.

[Isomorphic]

The dragRepositionCursor is the one shown when you mouse over a Canvas that can be drag repositioned.

We can't tell which cursor you're talking about. Before drag? During drag?

We also can't tell whether you're talking about something that can be dragged (in which case the dragRepositionCursor setting would apply) or just a container of things that can be dragged (in which case it wouldn't, and just canvas.cursor applies).

[dbscott525]

I have two canvases. One is com.smartgwt.client.widgets.Img and the other is com.smartgwt.client.widgets.layout.HLayout.

The drag settings for both of these are identical:

canvas.setCanDragReposition([B]true[/B]);
canvas.setCanDrop([B]true[/B]);
canvas.setDragAppearance(DragAppearance.[B][I]TARGET[/I][/B]);
canvas.setDragType(name());

When hovering over these I get two different cursors. I have attached screenshots of each.

[dbscott525]

I have further discovery about this problem. I found that elsewhere in our code we were setting the cursor to Cursor.POINTER. So I removed the call to set the cursor and now the cursor becomes the standard cursor. I changed the cursor to Cursor.MOVE and now I get the desired effect.

Some questions:

1. I have to set the cursor on every canvas contained within the layout to have the cursor be the same for anything contained in the layout. Why doesn’t it work to set the cursor in the layout and have that be the cursor not matter where it hovers over the layout?
2. Why is the cursor set automatically to Cursor.MOVE for Img but not for the Layout when I set the various drag options?

At this point the problem is resolved. So answers to the questions above are not needed for me to solve the problem, but it would be helpful to understand how this works.

I have some additional information about the display anomaly. In the code, the parent of the item being dragged is destroyed (canvas.destroy()) after the drop is canceled. Maybe this accounts for the display of the dragged item to stay where it was last dragged even if the drag was canceled.

When a layout is destroyed what happens to its members? Are they destroyed as well? Is it best practice to also destroy all the members?

[Isomorphic]

1. Because if it worked that way, any time you set a cursor on a parent, you have to manually re-establish normal cursor behavior for various common children, like Buttons, text fields, drop-downs..

2. We'd have to see complete code that shows this effect. That's not normal and probably has to do with code you've added elsewhere again

When a Layout is destroyed, so are all members. Best practice is to just destroy the Layout. Destroying the members first would cause the Layout to go through unnecessary work reacting unnecessarily as each member is destroyed (resizing other members, etc). For more background and advice, see the docs for Canvas.destroy() and the Memory Leaks overview.