Path: utzoo!attcan!uunet!husc6!bloom-beacon!3d.DEC.COM!fanning
From: fanning@3d.DEC.COM
Newsgroups: comp.windows.x
Subject: Re:  Problem with Xtoolkit example
Message-ID: <8807121404.AA08758@decwrl.dec.com>
Date: 12 Jul 88 14:04:27 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 50


	
>From: 3d::decwrl::ardent!mlp@uunet.uu.net (Mark Patrick  11-Jul-88 1454 PDT)
 
>The following example taken from the paper "Using the X Toolkit or How to
>Write a Widget" by Joel McCormack and Paul Asente appears to have a problem
>on the X toolkit implementations (including the sun) which we have access to.
>The program is given below:
	.
	.
	.
	.
>The line which reads:
>
>	XtSetArg(arg[n], XtNfromVert, label); n++;
>
>appears to be essential for the command widget to be displayed.  Does anyone
>know if this line really should be there of if there is a problem with the
>X toolkit
 
 
The command widget is displayed with or without that line.  If, however,
the XtNfromVert argument is left equal to its default value (NULL), then
the form widget which parents both the label and command widgets tries to
put them both XtNvertDistance (XtDefaultDistance) from its top.  This results 
in the widgets overlapping one another. 
 
The reason that the first widget created (not the first widget managed)
overlaps the second traces back to the following two facts : 
	
	o	The insert_child procedure for the form widget by
		default places a newly created child on the end
		of its array or queue of children.
 
	o	XtRealizeWidget calls RealizeWidget, which traverses
		the children of a composite widget in postfix order,
		meaning that the last child in the queue is realized
		first and the first is realized last (pretty biblical, huh?).
		In other words, a composite widget's array of children
		is realized and displayed from the last created to the 
		first created.
 
 
 
Blaise Fanning
Digital Equipment Corporation
Workstation Graphics
Marlboro, MA