Cut/copying and pasting custom object types

[dave taubler]

I've got a Swing application which makes a lot of use of cut & paste operations. I use the standard Toolkit, Clipboard, DataFlavor, etc classes. Throughtout various parts of the application, users might be cutting & pasting text and images, as well visual layout widget that are of a custom type that I created (the application is sort of a design/layout application). Obviously, I want to user's experience to be seamless; e.g. if the user copies text and then pastes into the app, text is pasted; if they copy an image from somewhere and then paste into the app, and image is pasted; and if they copy a layout widget from the app and then paste, a duplicate layout widget is pasted. Whatever's on the clipboard gets pasted.

So my problem is that I think I'm handling the latter case, the custom layout widget, incorrectly. I've created a custom Transferable, WidgetListSelection, whose sole supported DataFlavor is DataFlavor.javaFileListFlavor. When the user selects one or more widgets and then copies them, a WidgetListSelection containing a List of the selected Widgets is placed on the clipboard.

This actually worked, until OX 10.5, Leopard, came out for the Mac; now it doesn't. I haven't found any bug reports related to cut/paste on Leopard, and I guess I'm at the very least misusing DataFlavor.javaFileListFlavor. So I figure it's my bad, not Leopard's.

My thought for a solution was just to place the copied widgets into a List somewhere (not on the Clipboard), and then place something like a unique String on the Clipboard itself. Then when the user pastes, I check the Clipboard contents for that unique String. If I find it, then I grab the Widgets from that List and paste them.

Obviously, there are a few things that smell wrong about that approach. But, what would be the right approach? Anyone have any experience in copying/pasting custom object types that aren't text or images using the Clipboard? I should clarify that these objects have no relevance outside of my application, but I want to use the Clipboard mechanism to keep things seamless for the user.

[dave taubler]

Alrighty, after some research, I'm going to create my own DataFlavor and specify that it's a JVM local type, via the DataFlavor constructor that takes a String that contains DataFlavor.javaJVMLocalObjectMimeType. It looks like that's the right approach to take, and we'll see if it solves by Leopard problem as well.

[dave taubler]

I feel like I'm talking to myself here...

Anyway, in case anyone stumbles across this in the future with a similar issue, what I wound up doing is creating my own DataFlavor and declaring the data type as an ArrayList thusly:

DataFlavor widgetListDataFlavor =
  new DataFlavor(DataFlavor.javaJVMLocalObjectMimeType + ";class=java.util.ArrayList");

I soon realized that this would be tricky, since the JVM would serialize all of the widgets being copied. First, I had to go through and make all widgets implement Serializable (no big deal) and ensure that they all had serialVersionUID set. But soon I realized that my widgets weren't as decoupled from my app as I'd thought, and that I'd probably wind up serializing an instance of pretty much every class in my app. I started going through and marking some fields as transient, but for various reasons I determined that approach wouldn't work out.

I already have methods to output my widgets as XML, so that's the next and apporach I took. My DataFlavor now looks like this:

DataFlavor widgetListDataFlavor =
  new DataFlavor(DataFlavor.javaJVMLocalObjectMimeType + ";class=java.lang.String");

(changing java.util.ArrayList to java.lang.String). The data that gets copied is now--rather than an ArrayList of widgets--actually a String/XML representation of the widgets. When the user pastes, I do something like:

String xml = (String)clipboardContents.getTransferData(widgetListDataFlavor);

I then parse xml to derive the widgets to be pasted.

[Brian Cole]

Originally posted by dave taubler:
what I wound up doing is creating my own DataFlavor and declaring the data type as an ArrayList thusly:

DataFlavor widgetListDataFlavor =
  new DataFlavor(DataFlavor.javaJVMLocalObjectMimeType + ";class=java.util.ArrayList");

I soon realized that this would be tricky, since the JVM would serialize all of the widgets being copied.

Well the whole point of using DataFlavor.javaJVMLocalObjectMimeType+";class=the.fully.qualified.ClassName" is so that the JVM will not serialize the objects. I can assure you it does work.

First, I had to go through and make all widgets implement Serializable (no big deal) and ensure that they all had serialVersionUID set. But soon I realized that my widgets weren't as decoupled from my app as I'd thought

Did you actually use that data flavor above? It should work fine with non-Serializable objects, but I have never tried using javaJVMLocalObjectMimeType with a type that implemented Serializable. I think that it's supposed to work even so, but a quick search shows that some have had problems.

Since ArrayList does implement Serializable, I guess the obvious work-around it to write a custom wrapper that doesn't implement Serializable, so something like DataFlavor.javaJVMLocalObjectMimeType+";class=com.myCompany.myPackage.MyArrayListWrapper".

I already have methods to output my widgets as XML, so that's the next and apporach I took. My DataFlavor now looks like this:

DataFlavor widgetListDataFlavor =
  new DataFlavor(DataFlavor.javaJVMLocalObjectMimeType + ";class=java.lang.String");

(changing java.util.ArrayList to java.lang.String). The data that gets copied is now--rather than an ArrayList of widgets--actually a String/XML representation of the widgets.

Didn't you say that your objects weren't decoupled enough from your app?

Anyway, it's fine if it works, of course. You are essentially serializing and deserializing now, so you don't really need javaJVMLocalObjectMimeType in your flavor. It might be faster to leave it that way, though. Then again, it would be faster still to not serialize at all.

[edit: fix italic tags]
[ December 12, 2007: Message edited by: Brian Cole ]