This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
You can see this symptom in the Matisse's Inspector window. Steps to reproduce: 1. Create a JPanel form. 2. Add several JLabels to the JPanel. 3. Add a JButton to the Other Components node. 4. Now drag and drop the JButton between two JLabels. The JButton does get dropped (pasted) correctly but it is not inserted between the two JLabels but is inserted at the end. Actually I looked at the code. It seems that an attempt is made to support the reordering after a paste - when the dropped node's parent is different than the node that is being dropped on. It seems the following code: // finally perform the drop dtde.acceptDrop(dropAction); if (DnDConstants.ACTION_LINK == dropAction) { : : : } else { // get correct paste type PasteType pt = DragDropUtilities.getDropType( dropNode, ExplorerDnDManager.getDefault().getDraggedTransferable( (DnDConstants.ACTION_MOVE & dropAction) != 0 ), dropAction ); /*// help loop for all paste actions System.out.println("PASTE TYPES FOR "+dropAction); for (int i=0; i<pt.length; i++) { System.out.println(i+". "+pt [i].getName ()); }*/ Node[] diffNodes = DragDropUtilities.performPaste(pt, dropNode); ExplorerDnDManager.getDefault().setDraggedNodes(diffNodes); // check canReorder or optionally perform it if (canReorder(dropNode, diffNodes)) { performReorder(dropNode, diffNodes, lowerNodeIdx, upperNodeIdx); } } in method public void drop(DropTargetDropEvent dtde)of org.openide.explorer.view.TreeViewDropSupport makes an attempt to: 1. paste 2. reorder the pasted nodes It relies on the behavior of DragDropUtilities.performPaste() to return an array of new children. It seems this was done in response to an old issue: http://www.netbeans.org/issues/show_bug.cgi?id=37279 The code in DragDropUtilities.performPaste() basically takes a snapshot for children before and after paste operation and returns a diff: Node[] preNodes = targetFolder.getChildren().getNodes(true); // call paste action type.paste(); Node[] postNodes = targetFolder.getChildren().getNodes(true); However when I walk through the debugger I see that preNodes and postNodes are same i.e. postNodes does nto have the pasted children. Therefore the diffNodes array is of zero length and thus the following check in if ((folder == null) || (dragNodes.length == 0)) { return false; } in canReorder() fails and thus reordering does not happen.
Creator Shortfin needs this fix to support drag and drop of palette items in the right place on the new ExplorerManager based Outline (structural) view.
Created attachment 32496 [details] proposed patch
sandip, pls review to proposed patch and let me if it's working for you thanks
We do not build Netbeans anymore. Can you send me the module jar.
patched module jar should be in your mailbox now
I tried your patched jar with the Matisse's Inspector window scenario. It seems to work. However it results in two Undo events. In other words, there is one Undo event for the paste and second Undo for the reordering. I think this is unexpected. It seems to me that there needs to be some way for the Node implementations to know that a paste and reorder are caused by the single drop operation by the user.
after some more digging: a possible solution could be putting the dropped node to the proper position when the paste is performed. the subsequent 'reorder' would be a just a noop so the undo manager should have just one undo event then. i noticed that the explorer dnd manager ignores the drop index when the PasteType gets created by calling getDropType(Transferable t, int dropAction, int dropIndex). this is easy to fix in the explorer module but the default implementation of getDropType in AbstractNode calls createPasteTypes method which does not have the dropIndex argument. so if you have control over the drop node you could override getDropType method and perform the paste and reorder in one place. besided this i don't see any way to force the 'paste' and 'reorder' to be a single event from within the explorer dnd manager.
I do have control over the "drop" node and can override the getDropType (Transferable t, int dropAction, int dropIndex) method to record the index in the paste type. The problem is that the getDropType(Transferable t, int dropAction, int dropIndex) is always called with value of -1. Are you suggesting that you will fix it so that the getDropType(..., int dropIndex) will be called with the right index value? In that case go ahead and fix it.
sandip, i've emailed you patched jar fixing the dropIndex argument. pls let me know how it works for you.
I verified that I get correct values for drop index. So please go ahead and integrate those changes.
fixed in trunk please note that the reorder is invoked *after* the actual drop/paste operation so unless you override getDropType method in your Node to paste the dropped Node into correct position you may get two Undo events (one for the paste and one for reorder) Checking in DragDropUtilities.java; /cvs/openide/explorer/src/org/openide/explorer/view/DragDropUtilities.java,v <-- DragDropUtilities.java new revision: 1.10; previous revision: 1.9 done Checking in ListViewDropSupport.java; /cvs/openide/explorer/src/org/openide/explorer/view/ListViewDropSupport.java,v <-- ListViewDropSupport.java new revision: 1.7; previous revision: 1.6 done Checking in TreeViewDropSupport.java; /cvs/openide/explorer/src/org/openide/explorer/view/TreeViewDropSupport.java,v <-- TreeViewDropSupport.java new revision: 1.10; previous revision: 1.9 done
Created attachment 33399 [details] patch for release55 branch
fixed in release55 branch Checking in DragDropUtilities.java; /cvs/openide/explorer/src/org/openide/explorer/view/DragDropUtilities.java,v <-- DragDropUtilities.java new revision: 1.3.8.1.2.2; previous revision: 1.3.8.1.2.1 done Checking in ListViewDropSupport.java; /cvs/openide/explorer/src/org/openide/explorer/view/ListViewDropSupport.java,v <-- ListViewDropSupport.java new revision: 1.2.4.1.2.2; previous revision: 1.2.4.1.2.1 done Checking in TreeViewDropSupport.java; /cvs/openide/explorer/src/org/openide/explorer/view/TreeViewDropSupport.java,v <-- TreeViewDropSupport.java new revision: 1.1.14.1.2.2; previous revision: 1.1.14.1.2.1 done