One trick we've done occasionally when we know that things are going to change very frequently in tables is to not make all lists observable for all bean properties. Instead, we listen for specific changes and set a javax.swing.Timer to trigger a repaint in a few milliseconds in response to a list-changed (or other) event. The Timer isn't set to repeat. Multiple list-change (or other) events just coalesce into a single Timer trigger, which causes a single repaint (which in turn causes the table to re-render visible items, getting the most recent values).
It's not pretty, but it works wonders.
Sam
On Thu, Jun 25, 2009 at 2:04 PM, Kevin Day
<kevin@...> wrote:
I kind of like watching the counter go up and down :-)
Some random thoughts:
While dropping and adding the PCL would work, it doesn't feel like the right solution to me.
One way to do this would be to wrap the calculation in another calculation that incorporates a delayed firing mechanism, or one that fires the change from a different thread. If firing from a different thread, have the calculation grab a read lock on the source list to obtain the value. This should block until the list updates are all complete.
I'm kind of thinking of something along the lines of:
Calculations.waitUntilPipelineUnlocks(Calculation source, ReadLock lock)
something like that??
Any other thoughts out there in GL land?
- K
----------------------- Original Message -----------------------
Cc:
Date: Thu, 25 Jun 2009 06:25:31 -0700 (PDT)
Subject: Calculations.count notfies its listeners on each change of the list during a GlazedLists.replaceAllSorted
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
