every cell update event triggers getTableCellRendererComponent()

Note WPF is similar — PropertyChanged event is an invitation to “query ViewModel and display updates

If you use a swing timer to fire table update events, you will see, in log or debugger, that after every fireTableCellUpdated(a single cell), getTableCellRendererComponent() runs exactly once, on that single cell.

If you don’t use swing timer but use scheduleAtFixedRate() to call invokeLater(), which asynchronously calls fireTableCellUpdated(), you will see the same in the log file. However, debug session will likely show many fire() followed by a getTableCellRendererComponent(). This is illusion. It depends where you break-point — (Let’s say in both cases the event is scheduled to happen once a second. )

* If you break inside invokeLater’s Runnable.run(), you get confusing results. Scheduled tasks continue to call invokeLater() once a second, but your debug may suspend the EDT, so you might see many fire()
* If you break before invokeLater(), you should see one fire() followed by one getTableCellRendererComponent() — ABABABAB

No break point, then no surprise. Bottom line, each fire() is followed by a getTableCellRendererComponent() call. In plain English, after we fire each update event on a cell, that single “cell model” will get queried and rendered exactly once.

As in WPF, our code aren’t allowed to modify the visual component directly. Only way to effect a visual change is to update the model and fire events to invite “Hollywood” to requery the model and Notice the update.


Fill in your details below or click an icon to log in:

WordPress.com 徽标

您正在使用您的 WordPress.com 账号评论。 登出 /  更改 )

Google photo

您正在使用您的 Google 账号评论。 登出 /  更改 )

Twitter picture

您正在使用您的 Twitter 账号评论。 登出 /  更改 )

Facebook photo

您正在使用您的 Facebook 账号评论。 登出 /  更改 )

Connecting to %s