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.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s