Hi Thomas, what you should do is the following: - add a single "TList *fWidgets" to you class to which you add all widgets you create in your dialog. In the dialog dtor you then call "fWidgets->Delete()" to clean them all up in one go. (note I was mistaken in my previous mail, the TGCompositeFrame dtor does not delete the widgets it contains, it deletes only the wrapper objects in which the widgets are wrapped). - to avoid having to search for the widget pointer use instead of the ProcessMessage() event handling model the new signal/slot model. An extensive example can be found in guitest.C (as opposed to guitest.cxx which uses the ProcessMessage() method). See for example TestDialog::HandleButtons in guitest.C as an example where the system provides you directly a pointer to the button that caused the action. Note also that making a general way of finding a widget using its widget id is not possible. This method could only return you a TGWindow* (lowest common base class for all widgets) and then you would have to add a huge if statement where you would determine the actual widget's class and cast the widget to this class. Only then can you call the correct member functions for the widget. Cheers, Fons. Thomas Bretz wrote: > > Hi, > > in my opinion it isn't convinient to store pointers to all dialog > control in your class. For a dialog with many many controls it's getting > to be a real mess! And there is not a real need for it. > > In the constructor create your controls. > In the Process-Function process the messages and get the pointer from > some list only if you need them. > The controls can be deleted automatically. > > I think something like this would give your window-class a better > structure. > > Regards, > Thomas. -- 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 01 2002 - 17:50:35 MET