Edit Question - KnowledgeHub

Title Body

When writing GUIs, I've frequently come over the following problem: Assume you have a model and a controller. The controller has a widget W that is used to show a property X of the model. Because the model might be changed from outside the controller (there might be other controllers using the same model, undo operations etc), the controller listens to changes on the model. The controller also listens to events on the widget W and updates the property X accordingly. Now, the following happens: the value in W is changed an event is generated, the handler in the controller is invoked the controller sets the new value for X in the model the model emits events because it has been changed the controller receives a change event from the model the controller gets the value of X and sets it in the widget goto 1. There are several possible solutions for that: Modify the controller to set a flag when the model is updated, and not react to any events from the model if this flag is set. Disconnect the controller temporarily (or tell the model not to send any events for some time) Freeze any updates from the widget In the past, I usually went for option 1., because it's the simplest thing. It has the drawback of cluttering your classes with flags, but the other methods have their drawbacks, too. Just for the record, I've had this problem with several GUI toolkits, including GTK+, Qt and SWT, so I think it's pretty toolkit-agnostic. Any best practices? Or is the architecture I use simply wrong? @Shy: That's a solution for some cases, but you still get a round of superfluous events if X is c

Tags (comma-separated) Cancel