RPL Global User-defined Functions -- 4-9-2009 (1 of 2) http://cadswes2.colorado.edu/~philw/2009/GlobalRplFunctions/ Adding 'isGlobal' state to RplSets, accessible to all child RplObjs. Not yet part of the RplSet serialization. NOTE-1: A slightly more complex name for isGlobal accessor methods is used because of the inevitable confusion with method names which, very reasonably, include the word "set" in them, referring to a Rpl set (and not the verb, 'set'). For example, to 'set' the _isGlobal flag, I initially named the method: 'setIsGlobal'. That looks also like a predicate (about the 'set'). No good. NOTE-2: In Rpl, state change notifications to the GUI are not implemented at the 'model' (Rpl) level. They are implemented within the GUI (QtRpl) -- assuming that all changes the GUI would be concerned about are initiated _from_ the GUI. So, no callbacks were defined for changes to the 'isGlobal' state. [This was confirmed with Patrick]. -------------- Rpl/RplObj.hpp Rpl/RplObj.cpp -------------- New method: virtual bool rplSetIsGlobal() const; The implementation in the RplObj base class retrieves the containing RplSet, and calls this virtual method on that object. So, it is necessary for RplSet to override this virtual method (or else there would be infinite recursion). -------------- Rpl/RplSet.hpp Rpl/RplSet.cpp -------------- New data member: bool _isGlobal; // for Global RplSets and contained groups and blocks New methods: // virtual from RplObj virtual bool rplSetIsGlobal() const; // (return _isGlobal); void setRplSetIsGlobal (bool isGlobal); Also, added comments to the three constructors and supporting private methods regarding life-cycle issues, esp. for the dynamically allocated lists of dynamically allocated, owned RplGroups. (I had thought that I had found a leak, but actually, it wasn't. All calls to the private 'copy' method which needed to be concerned about the target RplSet already having defined lists DO, in fact, first call the 'deleteAll' private method. Comments were added to clarify). ---