Sorry to reply to myself, but:
Brett Viren writes:
> Ideally, "gPad" would be a smart pointer (ref counted handle). In
> this case, it could easily be modified to emit a signal when
> operator=() is used. Changing to this design now would break legions
> of user code.
I think I am wrong about the effects of changing gPad from it's
current CPP macro / static method into something better. I originally
thought that if gPad returned a ref counted smart pointer it would
solve things, but this isn't really what is wanted.
Instead if gPad was a global instance of a new class which manages the
real "currentPad" pointer then things would stay backward (source)
compatible and one could get notification whenever the current pad.
This class, call it "TGlobalPad", must implement all the necessary
operator methods so that it looks like a pointer to a TPad. In
addition its operator=() should emit some signal, say,
"GPadChanged()".
Something like:
// TGlobalPad.h:
extern TGlobalPad gPad;
class TGlobalPad {
TVirtualPad* fCurrentPad;
public:
// all methods for making it look like a pointer
// ...
virtual void GPadChanged() { Emit("GPadChanged()"); } //*SIGNAL*
TVirtualPad*& operator=(TVirtualPad*& newpad) {
// regular operator= code
// ...
GPadChanged();
}
//...
};
// TGlobalPad.cxx:
TGlobalPad gPad;
// Rest of imp....
So, now all one needs to do is find someone to implement it and get
ROOT to accept the patch....
-Brett.
PS: Extra bonus points for implementing this as a templated class
where gPad is defined like: TWatchedPointer<TVirtualPad> gPad; !!!
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:45 MET