views:

44

answers:

3

I have a GUI that is issuing commands to a web server based on slider values. Some of these sliders are "coupled" on the web server, so changing one of them may also change another one. The coupling is accomplished by the web server returning a list of the values that were set based on the the issued command.

So I can easily set the appropriate sliders based on this response, but the issue is that doing this causes the ChangeListener to be fired and then a command is issued to the web server again. Ideally, the "coupling" should be well behaved and avoid infinite loops, but that is a potential concern and send all those extra events seems unnecessary.

The two solutions I could think of were:

  1. Temporarily removing the listeners, changing the value, and then putting them back.
  2. Add a "manual" flag to let the listener know that it should ignore the change.

Neither of those seems like the ideal solution to me, but is one of them "better" than the other? Or is there a third solution that I'm not considering?

+1  A: 

add an enabled flag to the listeners and disable them before manually setting the value

I wouldn't add and remove listeners as that just triggers more listeners!

Pyrolistical
The potential for unexpected behavior (from issues with setting/unsetting the flag) in this solution still concerns me a little bit, but it appears to be the best solution available.
Dave Johansen
+2  A: 

One author calls this problem fibrillation. This discussion suggests a shared model, in addition to the flag approach suggested by @Pyrolistical.

trashgod
In this instance the difficulty of a shared model is that the "coupling" existing only on the server and is not known to my GUI, so implementing a shared model is non-trivial because it would basically be a model for the entire GUI.
Dave Johansen
I see. Is there a possibility to use `setValueIsAdjusting()` to control the flow of change events from the model?
trashgod
Filtering on `setValueIsAdjusting()` will definitely help reduce the number of events, but unfortunately it doesn't remove the issue with subsequent events being generated.
Dave Johansen
A: 

The standard model used in .Net WPF is to fire an event only if value of the property has changed! In your case it is setValue() method.

Mikhail