4

システム クリップボードの変更をリッスンするプログラムを作成しています。リスナーは別のスレッドで実行され、クリップボードの内容が変更されると何らかのアクション (ファイルへの書き込みなど) を実行します。

ClipboardOwner インターフェイスを使用してクリップボードをポーリングしているため、プログラムがクリップボードの所有権を失うと (別のプロセスがクリップボードを変更したことを意味します)、プログラムでイベントが発生し、変更を読み取ることができます。

public class OwnershipClipboardListener extends Thread implements ClipboardOwner
{
    private Clipboard clipB = Toolkit.getDefaultToolkit().getSystemClipboard();

    public void run()
    {
        /* Initialize ClipboardListener and gain ownership of clipboard */
    }

    @Override
    public void lostOwnership(Clipboard clipboard, Transferable transferable)
    {
        /* Auto-fired when I lose Clipboard ownership.
           Can do processing and regaining ownership here */
    }    
}

問題は、OSX で実行している場合、ドックで実行中のプロセス アイコンに手動で Cmd-Tab を押した場合にのみ、クリップボードへの変更が反映されることです。そのため、ドック アイコンに切り替える前に複数のクリップボード操作があった場合、最後の操作のみが有効になります。Linux または Windows では、この問題に直面していません。

プログラムがフォーカスを失ったときにスレッドがスリープ状態になるようなものですが、ウェイクアップ時に最後のイベント トリガーが引き続き発生します。この睡眠を防ぐ方法はありますか？

4

2 に答える 2

1

OSX はクリップボードの変更の通知を提供しないのではないかと思うので、Java は何らかの理由で起動されるたびに通知することで、最善を尽くしています。

私の疑いは、NSPasteboardのドキュメント、changeCount特にルーチンから来ています。「したがって、ペーストボードの所有権を取得した時点で変更カウントを記録し、後でそれを changeCount から返された値と比較して、まだ所有権があるかどうかを判断できます。」イベントを使用して変更を検出することについては言及されていません。

于 2012-04-06T05:11:12.293 に答える
0

キースは正しいようです。ただし、アプリケーションをバックグラウンド (*Nix 上) に送信することで回避策を実行できます。

java -jar clipboard-1.0.jar &

これにより、Java アプリケーションがバックグラウンドで開かれ、通知を起動するためにウィンドウ フォーカスは必要ありません。

于 2012-04-11T05:41:32.747 に答える