Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!agate!ucbvax!alphalpha.com!nazgul
From: nazgul@alphalpha.com (Kee Hinckley)
Newsgroups: comp.windows.x.motif
Subject: Re: C++ interface to Motif 1 of 2 (long)
Message-ID: <901119180308.847@alphalpha>
Date: 19 Nov 90 22:03:08 GMT
References: <9011191652.AA01032@dolphin.aet_austin>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 31

> > This is not an easy problem.  I fouled it up several times.  My solution was
> > to not actually use the destructor for the widget (except at the very
> > base class).  Particularly because in some instances I want to do
> > window cacheing and don't *really* want to destroy the widget.  What
> > I did was have the object constructor put a delete callback on the
> > widget.  When I want to destroy an object I call a special deleteWidget
> > member function.  That function then calls XtDestroyWidget on the
> > widget, which then calls back to destroy the object when the time
> > comes.  This allows caching and also ensures that the object doesn't
> > get referenced after it's been deleted.
> 
> I don't know if I follow all your reasoning here.  Since I create 99%
> of these wdiget objects using the new operator they are going to be
> around (cached) until I explicitly delete them.  Therefore the
> destructor seems to be the right place to put the widget destruction. 
That assumes that you always explicitly delete each widget.  In fact this
is hardly ever the case (I mean you *could*, but it would be a pain).  In
fact you are more likely to delete the top-level object and expect all the
others to go away automatically (just like they do in Xt).  Assuming that
this is the case you now have two choices.  You can mimic the Xt hierarchy
and chase down the objects and explicitly delete them.  That would be
wrong.  Or you can tell the widgets to delete the objects when they
get destroyed (via an XmNdestroyCallback).  However if you do the
latter case, then you have the problem of not really knowing whether
this particular object was deleted via 'delete' from your code, or from the
Xt callback.  And you start running into situations where you delete it,
it deletes the widget, the widget callbacks and deletes the object *again*.
Definitely not good.  You can probably work these out, but I found it
easier to never explicitly delete a wrapper object, but instead to call
a method which deletes the widget, which then calls back and deletes
the object.  That ended up being much easier to keep track of.