1

だから私はこの問題を抱えています。ファイルを作成してロードするプログラムがあります。

プログラムにファイルをロードするとき、特定のコンポーネントがいつ「いっぱい」になるかを通知するコンポーネント リスナーに依存し、それに従ってすべてのコンポーネントを移動します。

各コンポーネントを一番上に追加し、親コンポーネントが「いっぱい」になったときにリスナーを登録し、一番下のコンポーネントをそれが作成する新しい親に移動します。これは、100 ページの MSWord 文書の先頭に新しいテキスト行を追加するものと考えてください。

そのリスナーは GUI の設定にも依存しています。メモリ内のすべてが画面に描画されていない場合、間違ったコンポーネントの高さ (通常は 0) を取得し、それらを計算に使用すると、結果が間違ってしまい、すべてが台無しになります。

これが私のプログラムのその部分のフローチャートです:

(すべての処理は JFrame の JPanel で行われます)

trigger opening method:
{
    repeat this x (lets say e.g. 100) times:
    {
        trigger addComponent method
        {
            add component
            {
                adding component triggers the component listner 8if there is no more room in parent)
                {
                    move all of the components one place down, move the ones out of bounds to next "page"
                    repaint and revalidate whole JFrame (inside listener)
                }
            }
            repaint and revalidate whole JFrame (part of addComponent method)
        }
        repaint and revalidate whole JFrame(part of opening methid, after component addition)       
    }
    repaint and revalidate whole JFrame (as a part of opening method, final repaint/validate)
}

これが再描画/検証される理由は、addComponent メソッドと同様に、リスナーに他の関数があり、再描画/検証のための唯一の (最適な) 場所である他の場所で呼び出されるためです。

問題は、JFrame が操作メソッドでの最後の (最終) 検証/再描画呼び出しまで再描画されないことです。これを証明するために、(検証/再描画の後) コードのいくつかの場所に Thread.sleep(1000) を追加しようとしました。

また、私の知る限り、コンポーネントリスナーがトリガーされると、それをトリガーした行で停止し、それ自体を実行してから、その行から続行しますよね?

これを修正するにはどうすればよいですか? 新しいコンポーネントが追加されるたびにプログラムを再描画/検証するように強制するにはどうすればよいですか?

最初の 2 つのコメントへの返信: まず、Thread.sleep(1000) は問題を診断するためのものでした。Thread.sleep(1000) メソッドが repaint/validate メソッドであった直前に、reapint() が呼び出された直後にプログラムを一時停止すると、一時停止するたびに GUI が再描画され、新しい要素が追加されたことがわかりますが、そうではありませんでした。ケース。

第二に、長い計算に関しては、それらの計算はそれほど長くはありません (20 個のコンポーネントでこれを実行すると、望ましい結果ではありませんが、一時的な結果が得られます)。また、その計算では、GUI からコンポーネントを頻繁に (10 ~ 20 行ごとに) 削除および追加する必要があるため、その中に SwingWorker を組み込むことはほとんど不可能であり、必要ありません。

第三に、あなたは全体の要点を逃したと思います。実行の長さはここでは本当の問題ではなく、GUI がフリーズすることもありません (これは実際には発生しませんが、とにかく目立つほど長くはありません)。問題は、repaint/validate がループ内でコンポーネントごとに合計 3 ~ 4 回 (20 個のコンポーネントを含むファイルを開くと約 60 ~ 80 回) 呼び出されたことです。最後に呼び出されたとき、ループの後...

再描画/検証の直前と直後に System.out.println("something") メソッドを配置しました。「何か」を2回出力しましたが、再描画/検証は行われませんでした。

4

1 に答える 1

2
  • コンテナー内の/ e / JComponentsに関する問題addremovmodify確認できます( JFrame--> JPanelei)

  • コンテナ ( JPanelei) が配置されているかどうかによって異なりますJScrollPane

  • コンテナ内で/ e / s のpack()後に呼び出す必要があるかどうかによって異なります。次に、画面上で e のサイズを変更します(たとえば)。addremovmodify JComponentJFram

于 2012-09-29T14:00:13.177 に答える