Clipboard Change Notification

[Ian Shef]

Is there a way to be notified about all changes to the system clipboard?
How?

java.awt.datatransfer.Clipboard.addFlavorListener(FlavorListener listener)
only provides reliable notification (at least under Windows XP) if the
available DataFlavors have changed. I want to be notified if the clipboard
contents have been changed, even if the new contents have the same
DataFlavors as the previous contents.

I can force the issue by grabbing ownership of the clipboard via
clipboard.setContents(clipboard.getContents(null), this)
but this seems like an unfriendly act. Besides, if two such applications run
concurrently on the same host, they will grab control back and forth ad
nauseum.

I must be missing a better way.

 

[Ian Shef]

Is there a way to be notified about all changes to the system clipboard?
How?

<deleted explanation of
java.awt.datatransfer.Clipboard.addFlavorListener
and of
clipboard.setContents(clipboard.getContents(null), this) >

Before anybody suggests it, I think that polling the system clipboard and
comparing the current contents with the previous contents is also a poor
solution. There ought to be a better way!

 

[Steve W. Jackson]

<deleted explanation of
java.awt.datatransfer.Clipboard.addFlavorListener
and of
clipboard.setContents(clipboard.getContents(null), this) >

Before anybody suggests it, I think that polling the system clipboard and
comparing the current contents with the previous contents is also a poor
solution. There ought to be a better way!

Seems to me that the ClipboardOwner interface should provide hat you
want. Unless I'm missing something.

Per the Javadocs, an instance of the interface becomes the owner of a
clipboard's contents if it's passed as an argument to a clipboard's
setContents. Then its lostOwnership method will serve as a listener in
the event that any other owner (within the same app or externally) puts
data there and thus becomes the clipboard's owner.

= Steve =

 

[Oliver Wong]

Seems to me that the ClipboardOwner interface should provide hat you
want. Unless I'm missing something.

Per the Javadocs, an instance of the interface becomes the owner of a
clipboard's contents if it's passed as an argument to a clipboard's
setContents. Then its lostOwnership method will serve as a listener in
the event that any other owner (within the same app or externally) puts
data there and thus becomes the clipboard's owner.

What if the app doesn't currently own the clipboard, but wants to
monitor it? If the clipboard changes, since the current app is not the
owner, it will not be notified of lost of ownership.

- Oliver

 

[Ian Shef]

What if the app doesn't currently own the clipboard, but wants to
monitor it? If the clipboard changes, since the current app is not the
owner, it will not be notified of lost of ownership.

- Oliver

Exactly -- lostOwnership() is what I was talking about when I discussed
avoiding
clipboard.setContents(clipboard.getContents(null), this)

"this" (or whatever object is used for this parameter) must implement
ClipboardOwner and becomes the owner of the clipboard. However, this feels
unfriendly, it is wasteful (because becoming clipboard owner while
maintaining the contents of the clipboard requires getting the current
contents and putting them back), and because it can cause conflicts with
other tasks that do the same thing. Thanks, Steve, for the suggestion, but
I already experimented with that approach.

In line with Oliver's comments, I am hoping for something better. I want
to monitor what _other_ applications put onto the clipboard but I only want
to affect the clipboard when I recognize that particular new content has
been provided.

There ought to be a better way.

 

[Ian Shef]

<deleted explanation of
java.awt.datatransfer.Clipboard.addFlavorListener
and of
clipboard.setContents(clipboard.getContents(null), this) >

Before anybody suggests it, I think that polling the system clipboard and
comparing the current contents with the previous contents is also a poor
solution. There ought to be a better way!

A followup to my own article...

It appears that Sun Developer Network Bug ID # 4259272 explains why this is
the way that it is: (1) notifying listeners about changes to DataFlavors
allows them to enable/disable their paste menu items. (2) Content change
notifications are available on some platforms but not others (e.g. not on
X11). It was deemed too expensive for Java to internally perform the polling
and comparison needed on these platforms, and the option to have an API to
ask whether contents change notifications are supported was dropped due to
insufficient demand.

Looks like I will have to perform my own polling. Sigh.