难以理解swing的JTable和JTree的渲染器机制 [英] Difficulties understanding the renderers mechanism of swing's JTable and JTree

查看:174
本文介绍了难以理解swing的JTable和JTree的渲染器机制的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

通常,当使用 JTable JTree 时,用户会写入并指定它是自己的特定单元格渲染器。

Often, when using JTable or JTree user writes and assign it is own specific cell renderer.

DefaultTableCellRenderer 继承用户的组件是很常见的,并实现了渲染器方法 getTableCellRendererComponent 。事实证明, DefaultTableCellRenderer 实际上是从JLabel继承的,因此当调用super(在render方法中)时返回自己(this),因此用户的渲染器可以类似地返回自己(这)以及。

It is very common to inherit user's component from DefaultTableCellRenderer, and implements the renderer method getTableCellRendererComponent. It turns out that DefaultTableCellRenderer in fact inherits from JLabel, thus returns himself (this) when called to super (at the render method) and thus user's renderer can similarly returns himself (this) as well.

这一切都运作良好。

我的问题是它怎么样?

My question is how can it be?

每次表调用此方法时,都会给出不同的参数,并根据这些参数更改输出标签。如果它确实是标签的同一个实例 - 不应该根据最后一次调用此方法进行更改吗?
这是不是意味着所有表格的单元格都是由相同的标签实例组成的,该标签实例保持相同的值(最后一次调用渲染器方法的值)?

Each time this method is called by the table, it is given different parameters, and the output label is changed as function of these parameters. If it is indeed the same instance of the label – shouldn't it be changed according to the last call to this method? Wouldn't it mean that all of the table's cells are infect composed of the same label instance, which holds the same value (value of last call to the renderer method)?

我在网上搜索过,并在Swing的代码中挖掘,找不到任何实际重复输出标签的 clone 复制构造函数的行为。
我找不到任何证据表明(可能)swing使用反射,以便每次从头开始重新实例化渲染器。

I have searched the web, and dig within Swing's code, and could not find any act of clone or copy constructor that actually duplicates the output label. I could not find any evidence that (perhaps) swing uses reflection in order to re-instantiate the renderer each time from scratch.

我读过Swing的关于JTables的教程,在那里我可以找到下一行:

I have read the Swing's tutorial on JTables, and there I could find the next lines:


你可能会期待表中的每个单元格都是一个组件。但是,出于性能原因,Swing表的实现方式不同。
相反,单个单元格渲染器通常用于绘制包含相同类型数据的所有单元格。您可以将渲染器视为可配置的墨迹标记,该表用于将适当格式化的数据标记到每个单元格上。当用户开始编辑单元格的数据时,单元格编辑器会接管单元格,控制单元格的编辑行为。

他们给出了一个提示,确实我所说的是正确的,但不解释它是如何实现的。

They give a hint, that indeed what I am saying is correct, but do not explain how its actually being accomplished.

我无法得到它。可以吗?

I can't get it. Can any of you?

推荐答案

这是 flyweight模式

当JTable重新绘制自身时,它会启动一个循环并迭代每个必须绘制的单元格。

When the JTable repaints itself, it starts a loop and iterates over every cell that must be painted.

对于每个单元格,它使用与单元格对应的参数调用渲染器。渲染器返回一个组件。此组件绘制在与当前表格单元格对应的矩形中。

For each cell, it invokes the renderer with the arguments corresponding to the cell. The renderer returns a component. This component is painted in the rectangle corresponding to the current table cell.

然后为下一个单元格调用渲染器,返回的组件(例如,具有不同的文本和颜色)被绘制在对应于单元格等。

Then the renderer is called for the next cell, and the returned component (which has a different text and color, for example), is painted in the rectangle corresponding to the cell, etc.

想象一下,每次调用渲染器时,都会获取返回组件的屏幕截图并将其粘贴到表格单元格中。

Imagine that each time the renderer is called, a screenshot of the returned component is taken and pasted into the table cell.

这篇关于难以理解swing的JTable和JTree的渲染器机制的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆