View Full Version : Getting the clipboard and keeping program up

12-05-2011, 05:16 AM
How do you keep a Java program "on the watch" for checking if the clipboard has been changed AND getting the clipboard information (without the use of awt)?

12-05-2011, 02:01 PM
I don't think you can. Clipboard is a system tool, so the AWT is likely required to interact with it. Just using the Clipboard and a FlavorListener should be sufficient to detect a change in the clipboard.
You'll want to do some reading on the best implementations too. Seems that the flavorlistener has its fair share of issues overall.

12-05-2011, 06:33 PM
What issues are they? The only 'useful' link I have found regarding FlavorListener is:

There's one more (http://stackoverflow.com/questions/5484927/listen-to-clipboard-changes-check-ownership) but I don't think its related to what I want to do.

12-05-2011, 07:09 PM
Reading the API sorta indicates that it may fire without any actual change. That's easy enough to get around by using a custom FlavorListener that tracks its known as well, and squelches the changes if nothing has actually been modified.
I've never used the FlavorListener though, so I can't be sure exactly what the issues are.

12-05-2011, 09:55 PM
Oh, I see.

I just want to confirm one more thing: I recently read that the AWT library just uses the native platform libraries to do GUI related stuff, and that Swing uses AWT but generates GUI thing look similar (but are not the same). Does that mean that I can technically use non-GUI AWT libraries on 'any' platform as well?

12-05-2011, 10:43 PM
The swing is lightweight. It implements most of its functionality through JVM emulation, although some of it is built directly on AWT (JFrame for an example). AWT has a higher reliance on the peer machine to handle its components. Both have pros and cons. Swing can (and most often does) interact with AWT as well (think of your Events for example).
If it works, my opinion is that AWT is the best choice. The problem is the cross-platform issue; I can't test this on every machine available, which is why I typically stick to Swing. I'd gladly choose something that is *supposed* to work across the board versus something that *may* work across the board. Even if by doing so I end up with a slower app (Swing is slower than AWT since it runs mostly via emulation).

Technically, you can use any AWT on cross platform (offhand I can't think of much that isn't directly linked to gui, which makes sense since it is the Abstract Windows Toolkit), and it *may* work. Sun has put a lot of work in the past into the AWT, SWT and swing, although IMO Swing has taken the spotlight.