問題タブ [event-dispatch-thread]

スイングパネルのラベルを毎秒更新するカウントダウンタイマー（関数内）を実装しました。これは次のコードです。

今、私の問題は、次のことをしたいときに私のコードの別の部分にあります：

だから問題は、ゲームを開始したいときに、タイマーを定義して割り当て、開始コマンドを与えて、タイマーが表示されるはずの画面に移動することです（JLabel更新）。
それでも、すでにカウントされているはずですが（タイマーを表示する画面の前でも）、まだ遅延があります。タイマーを表示するパネルが表示され、約2秒後にJlabel表示されてカウントダウンが開始されます。私がやっている時間に
すぐに更新されないイベントディスパッチスレッドが原因だと思いますJlabelJlabel.setText()

表示を遅らせることなくゲームを開始するにはどうすればよいJlabelですか？
ありがとう

さまざまな OS X バージョンの Apple JVM は、必要なときに WindowClosing イベントを生成しないという点で壊れているようです (たとえば、閉じるボタンをクリックしてアプリのメイン JFrame を閉じた場合)。

(最新の Apple Java アップデートでは、イベントを強制的に生成するプロパティを設定できますが、これは私が探しているものではありません)

私の問題は単純です。ユーザーがアプリを閉じたときに「ヒント」を表示したいと思います。ただし、(イベントが生成されないため) ユーザーがウィンドウを閉じたことを検出できません。

だから私はシャットダウンフックを使うことができると思った:

ただし、シャットダウン フックから JFrame を作成することには問題があるようです。シャットダウン フックが呼び出されると、EDT が既になくなっているようです。

私はいくつかのことを試しましたが、何も意味がないようです: 私の「ヒント」JFrame がすべて灰色のまま (シャットダウンフック以外の場所から呼び出されたときに正常に動作しているにもかかわらず) や、プログラムがすぐに終了するなどです。ラッチを使用して、シャットダウン フックからのラッチを待機しようとしましたが、EDT がもう存在しないかのようです。

私は現在、回避策としてツールチップを表示するためだけに 2 つ目の Java アプリを生成することを真剣に検討していますが、それは少しやり過ぎだと思います (ただし、少なくとも機能するでしょう)。

シャットダウン フックからウィンドウを作成し、EDT で何かを呼び出そうとした人はいますか?注意すべき問題はありますか? (非常に長い間知られている Apple VM のバグのため、OS X でウィンドウを閉じるイベントを確実にキャッチできないことを思い出してください)。

イベント表示スレッド（EDT）からどのイベントが管理されるかを理解しようとしています。

単純なもの、つまりJOptionPaneを単純に開き、ユーザーの応答を待ってから閉じる単純なコードを想定してみましょう。このオブジェクトに関連するどのイベントが現在EDTに配置されていますか？それは：a）オブジェクト（JOptionPane）の作成だけです。b）オブジェクトの存続期間中のすべてのオブジェクト関連イベント。C）何か他のもの（具体的に記入してください）。

ありがとうございました、

エリオット

下記参照：

EDT で doInBackground から特定の関数を実行したいと考えています。私は現在、問題なく動作しているパブリッシュとプロセスを使用してセットアップしています。ただし、パブリッシュとプロセスを使用せずに doInBackground から EDT で関数を実行する方法があるかどうかを知りたいです。また、invokeLater を使用せずに。どうにかしてこれを行うことはできますか？

これは、Eclipseでデバッグするときに私が抱える小さな煩わしさです。[キャッチされなかった例外で実行を一時停止する]をオンにすると、デバッガーは通常、例外がスローされた場所でスレッドを一時停止します。ただし、イベントディスパッチスレッドの例外により、EventDispatchThread.run（）の最後の行で一時停止します。スタックトレースをコンソールに出力できるようにするためにスレッドを再開するまで、例外が何であるか、または何が原因であるかについての有用な情報はありません。

Eclipseで次のコードをデバッグして、次のことを示します。

そして、例外がスローされた後の様子は次のとおりです。

2011年10月21日編集： EclipseまたはJavaデバッガーでは何も奇妙なことは起こっていないと思います。それは、EventDispatchThread.pumpOneEventForFilters（int）で例外がキャッチされて再スローされるだけです。Eclipseに「キャッチされて再スローされる可能性のある例外の実行を一時停止する」ように指示する方法はないと思います。残念な。

1.私のコードが私が持っているJPanelのある行にあると考えてください、私は自動的にEDTにいますか？

2. GUI、JPanelsまたは他のビュークラスに属していない他のすべてのクラス、単純な論理クラスについても同じ質問。

3.音楽を再生しているJPanelがある場合、音楽はイベントディスパッチスレッドまたはEDTではない他のスレッドで実行する必要があります（実行に問題はありませんでしたが、GUIをブロックしないため） EDTから）？

SwingUtilities.isEventDispatchThread()
注： Thanksを使用せずにそれを知る方法の一般的なルールが必要です

以前の投稿で Inerdia と話し合ったように、
JPanel (確かに EDT - メソッド チェックでチェックした) を使用していて、いくつかのアニメーション スレッド (スレッド拡張 Thread) を呼び出して内部で開始すると、何かがまだ奇妙です。チェックでEDTに参加していないスレッド。
アニメーションは EDT である必要があるため、アニメーション メソッドを runnable と invokeAndWait() でラップしましたが、前に述べたようにそのコードを呼び出しているときに、EDT ではないアニメーション スレッドでそれを取得しました。はEDTにあるので、私のinvokeLaterはそのアニメーションをEDTに配置していないようですか? 何故ですか？

関連するコード (animate メソッドを runnable でラップし、後で呼び出すために渡す前:
したがって、JPanel 上に次の行があります:

実装は次のとおりです。

私は、swing がスレッドセーフではないことを学びました。さらに深く掘り下げると、マルチスレッドに関連するさまざまな問題を防ぐために、swing コンポーネントへのすべての変更をイベント ディスパッチ スレッドで行う必要があることがわかりました。しかし、情報はそこで完全に止まっているように見えました。インターネット上でアクセス可能な場所ならどこでもこれを行う方法を説明する優れたチュートリアルはないようです。

他の問題に関連して投稿されたコードからの情報をまとめてパッチを当てると、プログラム内のすべてのスイング変更の周りに乱雑なコード ブロックを配置する必要があるように思われました (自分のコードのこの例のように):

基本、これでいいの？コード内の Swing コンポーネントを変更するたびに、そのコード (または invokeLater と同等のもの) を配置する必要がありますか?

また、Swing がこれを自動的に行わないのはなぜですか?

わかりました、これは本当に奇妙です。アプリケーションが初めてJFileChooserを開くたびに、IOExceptionがスローされ、一部のアイコンが正しく表示されません。

エラーを掘り下げてみると、1つのアイコンでヘッダーを読み取ろうとすると、最初の8バイトしか取得されないように見えますが、これでは不十分です。アイコンファイルを確認しましたが、すべて問題ないようです。このエラーの前に正しくロードされる別のアイコンファイルでアイコンファイルをオーバーライドしようとしましたが、同じことです。

このエラーを壊したときの私のスタックは次のとおりです。

これがGifImageDecoderインスタンスを掘り下げるときの私の変数値です。

通常、この画像データははるかに大きいはずです。最初の10バイトはヘッダーですが、ご覧のとおり8バイトしか取得しません。この例外の後、JFileChooserの他のすべてのアイコンが正しくロードされません。

これはreadHeader（）への適切な呼び出しです：

エラーをスローするアイコンの直前に、バッファにアイコンが完全にロードされます。

これがクラッシュする可能性のある場所の例です（システムアイコンを最初にロードするたびに、コードのいくつかの部分で発生します）：

それがsuper（file）に入ると、そこに行きます：

次に、上記の他のスレッドがアイコンを取得します（この投稿の2番目のスタックを参照）

申し訳ありませんが、少し長いですが、少し複雑です...

SwingWorkerは、APIが完全に可能で正常であると明確に述べているように、チャンクがprocess（）で合体して到着した場合に、解決に苦労している1つの厄介な問題を除いて、アプリで完全に期待どおりに機能します。

たとえば、「タスクが発生しています。お待ちください」というJDialogがある場合、問題が発生します。そのため、チャンクが公開され、doInBackground()そこに到着しprocess()てJDialogが設定されます。

doInBackgroundの長いタスクが終了したら、さらに2つのコマンドを「公開」します。1つは「JDialogのメッセージを「GUIが更新されるのを待っています」に変更します」、もう1つは「送信する結果をJTableに入力します」と言います。君"。

これについてのポイントは、TableModelのベクトルを置き換えるために大量の新しいデータをJTableに送信する場合、Swingは実際にそれ自体を更新するのに無視できない時間がかかる可能性があるということです...そのため、ユーザーに伝えたいと思います。 「長いタスクは終了しましたが、SwingがGUIを更新するのを待っています」。

奇妙なことに、これら2つの命令が2つの合体したチャンクとして到着した場合、JDialogは部分的にしか更新できないことがわかります。setTitle（ "blab"）により、JDialogのタイトルが変更されます...ただし、JDialogに対する他のすべての変更JTableのメインGUI更新が完了するまで保留になります。

チャンクの公開の間にdoInBackgroundでわずかな遅延が発生するように設計すれば、JDialogは正常に更新されます。明らかに、合体したチャンクでは、ループを使用して1つずつ通過するので、各ループの最後にタイマーを配置することを考えました。これは効果がありませんでした。

また、JDialogで「validate」と「paint」と「repaint」の無数の順列を試しました。

したがって、問題は、合体したチャンクを処理する反復の間に、process（）内でGUIを更新させる方法です。

注意：私は他のことも試しました。チャンクが複数ある場合は、チャンクを再公開します。これに伴う問題は、物事の非同期性を考えると、doInBackgroundに戻ると、必然的に物事が公開され続けるため、チャンクが間違った順序で公開される可能性があることです。さらに、この種のソリューションはエレガントではありません。

後で...要求に応じて、ここにSSCCEがあります。

...プログラムは5つの段階で構成されています：1）GUIを設定します2）「タスクが完了するのを待ちます」というメッセージを表示します3）「長い」非EDTタスク4）メッセージを変更して「GUIがテーブルを更新するのを待つ」と表示されます。5）GUIでテーブルを更新します（その後、JDialog / JOptionPaneを破棄します）。

私が理解していないのは、上記のdoInBackgroundのThread.sleep（）行をコメントアウトすると、JDialogの動作がおかしくなる理由です。タイトルは更新されますが、JOptionPaneのテキストは変更されず、「キャンセル」 「」ボタンは削除されません。

違いは、Thread.sleep（）行がないと、2つのチャンクが合体して到着し、EDTで次々に実行されることです...私は、最後に短いタイマーを実行するなどのことを試しました。 「チャンク処理ループ」、およびThread.yield（）の実験...基本的に、GUIにJDialogとそのすべてのコンポーネントを包括的に更新させようとしています...JTableの更新に進む前に...

どんな考えでもありがたいです。