Gideon crashes when opening a file in MDI mode

[David Faure]

On Wednesday 22 May 2002 08:59, Simon Hausmann wrote:
> (CC'ing David. It's about calling setManager( 0 ) in removePart in
> the PartManager)
> 
> On Tue, May 21, 2002 at 10:37:22PM +0200, Bernd Gehrmann wrote:
> > On Tuesday 21 May 2002 12:55, you wrote:
> > 
> > > Looks ... interesting, although I can read only half of the patch.
> > > Can you re-send it as unified diff with function names (-u -p) ?
> > 
> > Oops, here it is again ... but on second thought, I don't understand
> > what's really the problem and why it doesn't occur in other
> > applications.
> > 
> > Anyway, the "part->setManager(0)" part of the patch is certainly right :-)
> 
> Hm, yes. But it takes more than that. The slot connected to the
> part's destroyed() signal calls removePart() with sender(). If
> removedPart would call setManager, then in that case it would
> call it on a partially dead object, as the destroyed() signal is
> emitted from within the ~Object destructor.  I guess it would still
> work given that the object is allocated as one big chunk of memory,
> freed after the last dtor, but that's a hack ;-)

There's an easy fix for that.
Emit destroyed from Part::~Part(), and make sure we disconnect
from destroyed() in slotObjectDestroyed (or a method called by that one),
so that we don't react to QObject's destroyed().
If we can't emit destroyed(), create a new signal, partDestroyed().

This way removePart() will be called with a still-valid Part object.
Then from removePart we can do part->setManager(0).

-- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KDE, Making The Future of Computing Available Today