vix@ubvax.UB.Com (Paul Vixie) (04/07/88)
In my ever-more-bizarre quest for odd-looking menus, I've run into a situation
where I need to XtDestroyWidget() a couple of boxes-of-buttons and then immed-
iately create another box-of-buttons. All this is happening inside a large
Box with a hack I call XtNshrinkToFit set to FALSE (default=TRUE) to keep the
box from shrinking to its minimum possible size every time I breathe on it.
The new box-of-buttons (a menu) is created with a call to XtCreateWidget() for
a box (with another hack called XtNalignVertical set to TRUE (default=FALSE)),
then a bunch of XtCreateManagedWidget()'s for the buttons in the box, then a
XtManageChild(theBox). This all works, but there's some flashing I'd like to
better understand.
The new box-of-buttons flashes into position in the next available spot in the
outermost (XtNshrinkToFit=FALSE) box, then the box (or boxes) of buttons I'd
XtDestroyWidget()'ed disappears and the new box-of-buttons moves into the
space vacated by the two that are now gone. Note that in its temporary life
as a flash of light, the new box-of-buttons has its lines drawn but NOT its
text. All the lines -- the box itself and the boxes around the buttons. But
not the text. Before the text can be drawn, the whole thing is destroyed and
moved into the position vacated by the other boxes-of-buttons I'd previously
destroyed.
I thought to call this function after the XtDestroyWidget()'s and before the
creation of the new box-of-buttons:
static void
FlushEventQueue()
{
XEvent e;
while (XtPending()) {
XtNextEvent(&e);
XtDispatchEvent(&e);
}
}
Cute as it is, it changed nothing.
I think maybe the server is doing something to me as an optimization (which
makes sense, drawing text on a Sun in cgfour mode is very slow). Can anyone
offer a suggestion on how I can make the destroyed widgets go completely away
(handled by the parent widget, etc) so I don't get a window dance when I
create a new one in the same (parent) box?
--
Paul Vixie
Consultant Work: 408-562-7798 vix@ub.com vix%ubvax@uunet.uu.net
Ungermann-Bass Home: 415-647-7023 {amdahl,ptsfa,pyramid,uunet}!ubvax!vix
Santa Clara, CA <<I do not speak for Ungermann-Bass>>fred@hpcvlx.HP.COM (Fred Taft) (10/25/88)
You need to understand that destroying a widget is really a two phase process. When you make your call to XtDestroyWidget(), the toolkit simply marks each of the widgets as 'being destroyed'; at this point, nothing has been deleted (widgets, windows, children, etc). The next time you make a call to XtNextEvent (directly or by means of XtMainLoop), the first thing it does is check to see if there are any widgets waiting to be destroyed. If there are, then it finishes destroying them; this includes removing and destroying their windows, freeing up any resources they had allocated, freeing up their widget structure, and updating their parent's children list. At that point, it should be safe for you to create a new child of the shell widget. You can probably force the second phase of the destroy to occur by pushing a bogus event on the event queue, and then making a call to XtNextEvent() directly; you can then discard the bogus event it will return to you.
swick@ATHENA.MIT.EDU (Ralph R. Swick) (10/25/88)
> Date: 24 Oct 88 21:17:03 GMT > From: hp-pcd!hpcvlx!fred@hplabs.hp.com (Fred Taft) > ... > The next time you make > a call to XtNextEvent (directly or by means of XtMainLoop), the first thing > it does is check to see if there are any widgets waiting to be destroyed. Yes, this is the way Release 2 implemented the requirement that (Section 4.7) "Phase two occurs when all procedures that should execute as a result of the current event have been called." It was recognized (and documented) that this implementation was not completely satisfactory and it has been changed for Release 3 in a way similar to that described in "Issues 1 and 2" in the referenced section of the R2 documentation. In R3, when a call to XtDispatchEvent returns, all XtDestroyWidget calls made within that invocation of XtDispatchEvent will have completed.
twebb@pixel.UUCP (Tracy Webb) (10/11/90)
Hey,
We have an application that used to work but in now broken. We have converted all
Xt* to XtApp* where necessary but still we can't destroy our widget hierarchy.
Here's what were doing. Has anyone else had similar problems?? Anyone have a
clue as to what we're doing incorrectly & how to fix it???
static void quit_proc(w,data,call_data)
Widget w;
caddr_t data;
XmAnyCallbackStruct *call_data;
{
Widget w1,w2,w3;
w1 = XtParent(w);
w2 = XtParent(w1);
w3 = XtParent(w2);
XtDestroyWidget(w3);
}
Thanks for the help!!
Tracywytten@umn-cs.cs.umn.edu (Dale Wyttenbach) (02/02/91)
For the first time, I am writing an Xt application that doesn't use
XtMainLoop (because I don't want to exit when the event loop exits).
XtDestroyWidget doesn't make the window go away in my program. I
have studied the O'Reilly books and other application source. Here
is the relevent fragment:
/* go */
app_context = XtWidgetToApplicationContext(top_widget);
while (!alldone) { /* alldone is global */
XtAppNextEvent(app_context, &event);
XtDispatchEvent(&event);
}
XtDestroyWidget(top_widget);
return 0;
}
Please email suggestions. Thank you.
dale
--
____________________________wytten@cs.umn.edu__________________________________
Sam Stone came home
to his wife and family after serving in the conflict overseas
and the time that he served had shattered all his nervesbolt@fred.cs.utk.edu (David W. Bolt) (05/23/91)
I have an application that destroys and creates a form widget multiple times. Executing the destroy/create cycle several times causes the program to either crash or causes the geometry of the form widget to get altered. 1) is there a problem or precaution with this destroy/create cycle ? 2) is there a list of known problems with X can can be downloaded ?