Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 6 of 6
  1. #1
    Regular Coder Apothem's Avatar
    Join Date
    Mar 2008
    Posts
    380
    Thanks
    36
    Thanked 25 Times in 25 Posts

    Getting the clipboard and keeping program up

    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)?

  • #2
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    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.

  • Users who have thanked Fou-Lu for this post:

    Apothem (12-05-2011)

  • #3
    Regular Coder Apothem's Avatar
    Join Date
    Mar 2008
    Posts
    380
    Thanks
    36
    Thanked 25 Times in 25 Posts
    What issues are they? The only 'useful' link I have found regarding FlavorListener is:
    http://stackoverflow.com/questions/4...utside-of-java

    There's one more (http://stackoverflow.com/questions/5...heck-ownership) but I don't think its related to what I want to do.

  • #4
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    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.

  • #5
    Regular Coder Apothem's Avatar
    Join Date
    Mar 2008
    Posts
    380
    Thanks
    36
    Thanked 25 Times in 25 Posts
    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?

  • #6
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    Sorta.
    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.

  • Users who have thanked Fou-Lu for this post:

    Apothem (12-06-2011)


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •