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