Option to configure DNDAutoSelectSupport to accept or reject DnD transfers

Byte-Welt - Projekte / Projects DockingFrames
1

Hi Beni,

This is more of a feature request.

I am work on drag and drop functionality and require to:

1- open a new multiple dockable editor by dropping a file onto an empty working area drop location. (This works fine).
2- open a new multiple dockable editor by dropping a file onto the content area of an open editor. (This works fine).
3- open a new multiple dockable editor by dropping a file onto an editor’s title area. (The drop works fine but the title area does not grab the focus when the mouse hovers over it).
4- open a new multiple dockable editor by dropping a file onto an editor’s bar right up to the action buttons such as the close button. (Again, the drop works fine but the title area with the focus does not lose it when the mouse moves away from over it).
5- drop text onto a specific open editor (selecting it if necessary by hovering over its title area before the drop). (Not done yet, but the approach will be similar to number 3 above).

Whilst the first four requirements involve file drops during DnD, they simply create new multiple dockable editors (they do not drop file data inside existing open editors). The fifth requirement, however, drops text (not a file) inside an already open editor.

Looking at DF handling of DnD, I can see the two classes DNDAutoSelectSupport and DefaultDndAutoSelectStrategyRequest, and the three interfaces StackDnDAutoSelectSupport, DndAutoSelectStrategy, and DndAutoSelectStrategyRequest. I also note that canImport() in DNDAutoSelectSupport always returns ‘false’ – which explains the no-drop feedback during DnD operations over the editor area. At the same time I also note that the editor titles grab focus as the DND mouse hovers over them.

I can see that it is not recommended to change DNDAutoSelectSupport but since it does not match my requirements I have decided to disable DF DnD strategy altogether to achieve the above results,

(like this) control.putProperty(StackDockStation.DND_AUTO_SELECT_SUPPORT, null);

and implement my own TransferHandler.

However, I have now lost the capability for individual editors to grab focus provided by DefaultDndAutoSelectStrategyRequest; a capability which I need for my fifth requirement. This bit is the only thing I am missing; the rest is working fine (so far anyway).

Any ideas how to go about achieving this missing behaviour? The easiest way I see is to provide a configurable setting to enable /disable canImport() in DNDAutoSelectSupport to return ‘true /false’ and accept or reject a transfer. DF can still maintain its ‘false’ setting as default so it should not interfere with existing installations. Would this be something possible to implement? Or is there another option you may suggest, preferably something that I can include in my current TransferHandler? Thank you.

Adi

2

Can’t give you an answer right now, because I have to relearn how Java-DnD works :wink: I hope to find some spare time during the weekend to do so.

But you should be able to subclass DnDAutoSelectSupport, override the „canImport“ method, and install this customized class with „control.putProperty(StackDockStation.DND_AUTO_SELECT_SUPPORT, );“

3

Your tip did the trick! Everything is now working as expected! :wink:

For readers who are interested, here is what I did to make this work:

1- Created my own multiple dockable transfer handler from sub-classing DnDAutoSelectSupport. Due to several private members within DnDAutoSelectSupport, I had to copy all the code (yes, all of its members – including its single private variable) into my custom transfer handler. In my case, I only needed to comment out the last line ‚return false‘ in canImport(), and apply my own specific test conditions within canImport() method.

2- Configured DF to implement my newly created transfer handler as the DnD support:

		control.putProperty(StackDockStation.DND_AUTO_SELECT_SUPPORT, <instanceOfMyMultipleDockTransferHandler>);
		
		//If DF DnD strategy is not already set to the default, you can set it to enable multiple dockable titles to grab focus.
		control.putProperty(StackDockStation.DND_AUTO_SELECT_STRATEGY, DndAutoSelectStrategy.DEFAULT);

3- Finally, enable DnD functionality to the working area and the multiple dockable of interest by setting my customized handler as the DnD handler:

By default so far, only the multiple dockable title and bar areas accept DnD drops for my specific transfer handler. If you wish to make the content area of the multiple dockable accept the drop using your transfer handeler also – like in my case – then assign your customized transfer handler to the content object of interest within the dockable (such as JEditorPane, JTextPane, etc):

This assignment overrides the default Swing transfer handler already supported by JEditorPane and JTextPane components.

4- Done.

Beni – do you think there is a chance future upgrade versions of DF might break my approach above?
Thanks.

Adi

4

Quick update – just one improvement to my previous post.

Regarding step 1 above: there is no need to copy all of DnDAutoSelectSupport’s members. Simply sub-class DnDAutoSelectSupport and override canImport() only. All that is needed now is to call the following code on the first line:

	public boolean canImport(<classOfMyMultipleDockTransferHandler>.TransferSupport transferSupportIn) {
		super.canImport(transferSupportIn); //Call this on the first line. The call returns 'false', but you can now change it to 'true' if you wish, or let your tests below decide.
		...
		//Perform any required tests.
		...
		return true; //If necessary.
	}

Both approaches work, but the above updated approach is best practice, and more importantly is future-proof against future DF upgrades.

/Adi

5

Beni – do you think there is a chance future upgrade versions of DF might break my approach above?

I try to keep the framework backwards compatible - there is a good chance, that future versions will work. I won’t make promises, but I also do not have any plans on changing this code.