From xemacs-m  Thu Feb  6 09:59:05 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id JAA18031
	for <xemacs-beta@xemacs.org>; Thu, 6 Feb 1997 09:59:04 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQcbsx08563; Thu, 6 Feb 1997 10:59:04 -0500 (EST)
Date: Thu, 6 Feb 1997 10:59:04 -0500 (EST)
Message-Id: <QQcbsx08563.199702061559@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: Re: 20.0: another frame related crash
In-Reply-To: <199702061442.GAA22378@newman>
References: <QQcbqu26368.199702060204@crystal.WonderWorks.COM>
	<m2zpxi31b6.fsf@altair.xemacs.org>
	<199702061442.GAA22378@newman>

William M. Perry writes:
 > Steven L. Baur writes:
 > >Kyle Jones writes:
 > >
 > >> floating-toolbar killed this one.  mouse-3, boom!
 > >
 > >I think I figured out what is going on.  Frames that have popups can
 > >be deleted, but the popup's frame data structure isn't removed even
 > >though all the X11 objects have been killed by the server.  This patch
 > >(I hope) disables deletion of parent frames.  Your test case now stops
 > >with an error message.
 > 
 >   I would vote for just nuking the popup frames when you delete the
 > parent.  Seems reasonable behaviour.  Just need to make balloon-help and
 > floating-toolbar check for whether a frame is still alive when it goes to
 > pop it up or change the info in it.

They both already do.  The internal file dialog box code needed
to be checked.

