On Thu, 03 Feb 2011 18:47:19 +0100, Daniele Futtorovic
<da.futt.news@laposte.net.invalid> wrote, quoted or indirectly quoted
someone who said :
Why? The item's state *did* change, so it's only logical that an event
be fired.
Are you old enough to remember Walt Disney and the mousetraps and ping
pong balls? He balanced two ping pong balls on each of hundreds of
mousetraps then dropped a ball. In a second there was a simulation of
nuclear fission filmed in slow motion.
I had a similar problem with CurrCon. An applet on a page notifies the
other instances of the applet if the user has told it to use a
different currency. The problem was, when I programmatically set the
value of the currency in one of the other applet instances, that
instance could not tell it apart from a user changing it, so it TOO
decided to notify everyone, leading to a Disney fission.
What I do now is temporarily remove the listener for programmatic
notification, but not for human notification.
I ran similar problems in other programs with any sort of programmatic
setSelected triggering unnecessary events, or even endless ping pongs
trying to keep Components is logical sync. I thought others may have
the same problem, and it would be worthwhile to have a setSelected
(iii, boolean) that could suppress the ItemChanged event.
Yes, building convergent feedback systems is tricky.
Aesthetically debatable, but does the trick.