debounce_t< ModeType > Class Template Reference
|typedef boost::function< void(const |
|template<typename UnaryFunction1 , typename UnaryFunction2 >|
|debounce_t (const UnaryFunction1 &set_model_proc, const UnaryFunction2 &monitor_model_proc)|
|void||display (const model_type &new_value)|
|bool||is_monitor_model_proc_installed () const|
|bool||is_set_model_proc_installed () const|
|const model_type &||last () const|
|void||reset_monitor_model_proc (const proc_type &proc)|
|void||reset_set_model_proc (const proc_type &proc)|
|void||set_model_value (const model_type &from_controller)|
class adobe::debounce_t< ModeType >
When a "widget" models both a view and a controller, there can be issues of feedback loops. "Debouncing" is the process of detecting and short-circuiting these feedback loops. The loops have been broken into two types.
Type 1 feedback loops take place when the controller (typically owned by the OS) originates a change (presumably by manual user intervention). This change is propagated to the model as a request to change the value of a cell. The model, in turn, should then notify the view of the new cell value that it should display. Since the view is also the controller, we need to short-circuit at the point when the value comes back to the widget from the model. Since the controller's value may be altered by the model (which is the component carrying the state of the system) we track the value as it is being sent to the model and compare it going back out to the display.
Type 2 feedback takes place when the model is poked by a third-party controller, requiring the view of this widget to display something new. The model notifies the view, which then relays the information to the *actual* view, typically a control owned by the OS. Depending on the OS (Carbon being most notorious) the control may recieve back notification that its value has changed. Since the controller is also the view, we need to short-circuit at the point when the value comes back to the widget fromt the OS. Since the view is stateless within the system we do not care about the value being relayed by the OS to the controller. In this instance, then, using a flag to track type 2 feedback is sufficient.
Member Typedef Documentation
Constructor & Destructor Documentation
|debounce_t||(||const UnaryFunction1 &||set_model_proc,|
|const UnaryFunction2 &||monitor_model_proc|
/param set_model_proc This is the proc that will be called when the model needs to be notified that the controller has changed to a new value. This proc should point to the model.
/param monitor_model_proc This is the proc that will be called when the view needs to be notified that the model's cell has changed to a new value. This proc should point to the widget (OS).
Member Function Documentation
|void display||(||const model_type &||new_value )|
|void reset_monitor_model_proc||(||const proc_type &||proc )|
|void set_model_value||(||const model_type &||from_controller )|
Intended to be called by the widget (OS) whenever the value is changed (by either the user or if the OS chooses to feeedback). The proc will deduce the originator by retained internal state, and will opt to propagate the value to the model when appropriate.