On Sep 23, 2012, at 11:28 AM, Arshdeep Singh wrote:
In my courageous attempt at fixing bugs I came across this snippet where the variable setProgramatically eludes me:
void RegisteredCheckButton::setActive (bool b) { setProgrammatically = true; set_active (b); //The slave button is greyed out if the master button is unchecked for (std::listGtk::Widget*::const_iterator i = _slavewidgets.begin(); i != _slavewidgets.end(); ++i) { (*i)->set_sensitive(b); } setProgrammatically = false; }
Please help. Found in file <registered-widget.cpp>
Well... I've not chased down this specific instance, but I can give an overview of some of the patterns in play here.
First of all, "setProgrammatically" is a global variable or a member variable. Doing a quick find/grep to search source, I spotted it in registered-widget.h. It urns out to be a member, thus is on a per-widget basis.
The comment in the .h file helps a bit:
bool setProgrammatically; // true if the value was set by setActive, not changed by the user; // if a callback checks it, it must reset it back to false
The main reason for such toggles is to stop cyclic or runaway loops of recursive calls. It also helps distinguish between events triggered by the end user and those caused by side effects of changes in the middle.
There are a few different things to be done that we can clean up more properly, but for the short term being away of the two main reasons (tell if a user click was the source and prevent infinite loops of events and handlers).