Hi Brett,
have a look at guitest.C to, e.g. EntryTestDlg::EntryTestDlg, at:
fExitButton = new TGTextButton(fF2, " Close ", 1);
fExitButton->Connect("Clicked()", "EntryTestDlg", this, "DoOK()");
in DoOK() we do:
void EntryTestDlg::DoOK() { fMain->SendCloseMessage(); }
calling instead directly CloseWindow(){ delete this; }
will fail since after processing the signal the canvas including
the button issueing the signal is deleted (signal processing is
synchronous) while after the signal processing the button code
will still try accessing internals of the already deleted button
(resulting in badwindow calls to deleted button window). The
SendCloseMessage() makes the deletion process a-synchronous.
If this does not solve the problem let me know.
Cheers, Fons.
Brett Viren wrote:
>
> Hi Rooters,
>
> I am trying to understand how TGMainFrame derived windows are supposed
> to be correctly closed.
>
> What I have is a TGMainFrame which has various sub frames including
> TRootEmbeddedCanvases, some of which hold TPad derived classes as well
> as regular TPad and an assortment of custom and standard graphical
> TObjects. This TGMainFrame is spawned from a custom main which
> creates the TRint, provides the ROOT prompt and is expected to keep on
> running after the TGMainFrame is closed. This is all with compiled
> classes, not interpreted.
>
> Currently, in response to a TGButton's Clicked() signal I call
> TGMainFrame::CloseWindow() on the TGMainFrame derived object and then
> delete the object. This works, but then any <enter>s given to the
> ROOT prompt causes the ubiquitous BadWindow/BadPixmap X errors.
>
> This is with 3.01/06 28 August 2001 on x86 Linux, g++ 2.95, X4.1.0.
>
> Any help is appreciated,
>
> -Brett.
--
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 7679480
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:03 MET