8

これは一般的であることに気づきました。たとえば、DefaultListCellRenderer、DefaultTableCellRenderer、およびDefaultTreeCellRendererはすべてこれを使用します。また、私がオンラインで見ているカスタムセルレンダラーの多くもこれを使用しています。コードでカスタムTableCellRendererを使用したいのですが、本当にJLabelをサブクラス化する必要があるかどうかについて混乱しています。JLabelをサブクラス化する利点は何ですか？

4

3 に答える 3

10

DefaultTableCellRendererのAPIは次のように述べています。

テーブルクラスは単一のセルレンダラーを定義し、テーブル内のすべてのセルをレンダリングするためのラバースタンプとして使用します。最初のセルをレンダリングし、そのセルレンダラーの内容を変更し、原点を新しい場所に移動し、再描画します。標準コンポーネントはこのように使用するようには設計されていないため、セルが描画されるたびにJLabelトリガーされることは避けたいと考えています。メッセージはコンテナの階層を上って渡され、他のコンポーネントが影響を受けるかどうかを判断するrevalidateため、これによりパフォーマンスが大幅に低下します。revalidateレンダラーはペイント操作の存続期間中のみペアレント化されるため、同様に、ペイント操作の階層のウォークに関連するオーバーヘッドを回避したいと考えています。したがって、このクラスは、、、、をvalidateオーバーライドinvalidateしrevalidateますrepaint、およびメソッドは操作なしであり、パフォーマンスを向上させるためだけにメソッドfirePropertyChangeをオーバーライドします。isOpaque独自のレンダラーを作成する場合は、このパフォーマンスの考慮事項に留意してください。

于 2011-10-06T03:19:08.193 に答える
5

JLabelには、必要なすべての火力があり、次にいくつかの火力があります。テキストとアイコンを処理し、中央に配置でき、デフォルトで不透明でない背景があります。

于 2011-10-06T02:59:42.623 に答える
4

なぜなら、誰もが-初期のSwingチームでさえ-時々間違った方法で物事を行う権利があるからです:-)

また、レンダラーインターフェイスを実装する代わりにコンポーネントを拡張し、その実装をコンポーネントに委任するのは誤りです（これは、必要と思われるすべてのホイッスルを備えた特別に実装されたJLabelである可能性がありますが、個人的には確信が持てません）。DefaultTableCellRendererの不吉な「カラーメモリ」は直接的な結果です。

だから：Do-not-subclass-someComponent-to-implement-someRenderer。特にsomeComponent==DefaultTableCellRendererの場合は、壊れています。

ところで、SwingXはそれを正しく行います:-)

于 2011-10-06T10:07:18.237 に答える