I was using TBrowser objects in some code (writing a ROOT GUI) and I found a weird feature. From CINT, if you create a pointer to a TBrowser (popping up the browser window) and then use the mouse to close the window, it pushes the pointer out of scope. For example:
root [0] TBrowser* p = new TBrowser()
(while the browser window is open …)
root [1] p
(class TBrowser*)0x93b0270
(after the browser window has been closed …)
root [2] p
Error: Symbol p is not defined in current scope (tmpfile):1:
*** Interpreter error recovered ***
This presents some problems because I have a private member variable pointing to a TBrowser that gets pushed out of scope when the browser window is closed by the user. There seems to have been a conscious decision to remove these variables from the current scope (the same thing happens with TCanvas objects), so I was wondering why? I can work around this issue by naming my browser and calling gROOT->GetListOfBrowsers()->FindObject(“name”), but it seems a little overkill. It is also interesting that the TBrowser destructor does not push variables out of scope:
root [0] TBrowser* p = new TBrowser()
root [1] delete p
root [2] p
(class TBrowser*)0x0
This is a pure C++ behavior: when deleting an object, all pointers to this object become invalid - if you don’t explicitely set it to 0 (NULL)
Anyway, a possible solution would be to use signal/slots as shown there:
[code]#include “TBrowser.h” #include “TGFrame.h”
TBrowser *b;
void breset()
{
b = 0;
}
void btest()
{
b = new TBrowser();
TGMainFrame *main = dynamic_cast<TGMainFrame *>(b->GetBrowserImp());
if (main)
main->Connect(“CloseWindow()”, 0, 0, “breset()”);
}
[/code]
To run it, use ACLiC by typing .x btest.C+
You will have to adapt it to your specific application (and this should work for TCanvas too)
Thank you very much for your example, it works beautifully! Signals and slots are exactly what I need.
I am still a bit confused by what you say is a “pure C++ behavior”. I agree that when you delete an object, pointers to that object become invalid (they now point to an invalid address in memory). However, this should not cause them to go out of scope. These pointers can be reassigned to NULL or another object because they are still defined. When a pointer is pushed out of scope, it is no longer defined and therefore cannot be reassigned.
My question is:
Why does calling CloseWindow() push the TBrowser object (and all of the pointers attached to it) out of scope and why is this desired?
[quote]Why does calling CloseWindow() push the TBrowser object (and all of the pointers attached to it) out of scope and why is this desired?[/quote]This behavior is specific to CINT with the ROOT Gui. This ‘going out of scope’ is the way that was chosen to explicitly inform the script/interpreter user that the object being pointed by that variable is no longer available (especially due to a graphical interface action).
