Hi Stephen, here some answers, but without access to code it might be some guessing. FLOOR STEPHEN NICHOLAS wrote: > > Hello folks, I've been having some troubles with implementing a root-based > gui program. The program is quite large at this point so it's relatively > hard to track down the segmentation faults that occur. What tracking > down I have been able to do has pointed to problems in the ROOT class > destructors, namely GUI_RootCanvas.cxx, GUI_GMenu.cxx, GUI_GFrame.cxx and > quite a few other GUI related classes. I am quite certain, however, that > it is my implementation (not the original code) that is causing the > problems. I have some questions that will help me to get on > the right track. The main function of the program is to run a GUI that > has buttons which open a new window containing data. These buttons work > fine. Inside one of the 'subwindows' there are buttons to open a second > subwindow. It is at the closing of this second subwindow that the > problems occur. > > Questions: > > 1) Is it required to define the menubar for a canvas? If so, what is the > functionality of the Associate function? Is this function required? If > so, what should be passed to it if the class does not inherit from > TGMainFrame? > Any class that has to process messages must derive from TGFrame. Windows do not have to have a menubar. What do you mean with canvas (a TCanvas?). However, in the next release ROOT will support signal and slots like Qt which will make is trivial to hook up GUI components to any class (independent from the type of base class or from being compiled or interpreted). > > 2) The reason behind the first question yields the second. I receive > segmentation faults from the program when the 'x' is pressed in the corner > to close the window (also when you hit alt-f4 or choose close from the > menu). CloseWindow (and a relevant destructor) is defined for all the > classes involved, but they do not inherit from TGMainFrame or utilize > TGMainFrame. Is this required? I notice that it was used in the > Guitest.cxx example... > You must inherit from TGFrame for CloseWindow to do what you want. > > 3) What is the functionality of TGMainFrame? Would using TGMainFrame and > TRootEmbeddedCanvas be the best approach for a multi-window program, or > would TCanvas work better? If TRootEmbeddedCanvas is better, what > functions are there to replace TCanvas->cd(int_t) and TCanvas->Update()? > A TRootEmbeddedCanvas in a TGMainFrame gives more flexibility then the standard "pre-cooked" TCanvas. Use embedded->GetCanvas()->cd() and embedded->GetCanvas()->Update(). > > 3b) What is the function of TRootEmbeddedCanvas->AdoptCanvas(TGWindow *)? > Can this function be used to hold pointers as discussed in #4? > It is used to embed custom canvases derived from TCanvas. See the TRootEmbeddedCanvas constructor documentation. > > 4) How do multi-layered TCanvas's talk to each other? Is there a pointer > which keeps track of the 'parent' TCanvas? Is there a function to assign > this pointer? > All TCanvases are available via a global ROOT list: gROOT->GetListOfCanvases(). Also TCanvases embedded by TRootEmbeddedCanvas are in this list. > > Answers to all or even some of these questions I believe would solve the > problem. I have not attached code because it is quite lengthly but can do > in a future message if the need arises. > > Any help is greatly appreciated - reply to roottalk or snfloor@ukans.edu. > Thanks! > > -Stephen Floor Cheers, Fons. -- Org: CERN, European Laboratory for Particle Physics. Mail: 1211 Geneve 23, Switzerland E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248 WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7677910
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:35 MET