Path: utzoo!attcan!uunet!mcsun!ukc!harrier.ukc.ac.uk!rlh2
From: rlh2@ukc.ac.uk (Richard Hesketh)
Newsgroups: comp.windows.x
Subject: Re: Resetting fromHoriz or fromVert resources
Keywords: Form widget
Message-ID: <5601@harrier.ukc.ac.uk>
Date: 4 Oct 90 11:34:07 GMT
References: <84330@tut.cis.ohio-state.edu>
Reply-To: rlh2@ukc.ac.uk (Richard Hesketh)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 102

In article <84330@tut.cis.ohio-state.edu> Dr. Conleth S. O'Connell Jr. <cso@rose.cis.ohio-state.edu> writes:

>Hi there.  

Hello.

>The label widgets are placed in a form widget inside of a viewport
>widget inside of a toplevelShell widget.  After the descriptions, I'll
>include the declarations of the resources for these widgets.

>When I first create/place a label widget, everything works okay, i.e., the
>scrollbars are correct.  However, I am pretty printing the tree, e.g.,
>
>	       root
>	        |
>   -----------------------------
>   |            |              |
>child1	      child2        child3
>                |
>	   -----------
>	   |         |
>	child2.1  child2.2
>
>Pretty printing takes place as such for child2.1 for example:
>I want to place myself relative to the rightmost widget that I've seen
>so far (in a postfix traversal), in this case - child1.
>
>I get the x and width values of child1
>I get the x value of child2.1
>
>if I need to change the x value of child2.1, I make it 10 pixels + the
>x and width values of child1.
>
>I move the child2.1 widget with XtMoveWidget.
>What I want to do is just reset the fromHoriz resource, but nothing
>happens when I do this.  Any ideas?

By using the XtMoveWidget() you are completely overriding any child layout
performed by the Form widget.  The from{Horiz|Vert} resources are widget
id.s (not positions) and are used in conjunction with the other constraint
resources to tell the form how to layout the individual child.  The children
should never be moved using the XtMoveWidget() directly in an application.
XtMoveWidget() should only be used by a widget class itself to move its own
children around.

[ Ref: Athena Widget Set - C Language Interface Manual by Chris Peterson;
  Section 6.0.1: "Under no circumstances should an application programmer
  resort to XtMoveWidget() or XtResizeWidget(); these functions are
  excusively for the use of Composite widget implemetors." ]

>ANyway, because I am using XtMoveWidget one of two (or both) problems
>occur:

Again, this is all because you are breaking the whole geometry management
procedure implemented by the toolkit.  All application geometry changes
should be made through the SetValues interface which will then perform the
necessary changes and inform the various parents involved.

>Thanks for any explanation!

I would suggest two possible solutions:

1) Use the constraint resources of the Form to position children relative to
   siblings.  Such as:

	XtVaSetValues(child1, XtNfromVert, root, XtNfromHoriz, NULL,
			XtNvertDistance, Y_SEP_DIST, NULL);
	XtVaSetValues(child2, XtNfromVert, root, XtNfromHoriz, child1,
			XtNvertDistance, Y_SEP_DIST,
			XtNhorizDistance, X_SEP_DIST, NULL);
	followed by:
		XtUnmanageChild(child1);
		XtManageChild(child1);
	[ see notes below ]

2) Write your own constraint widget class that lays out its given children in
   a tree.  Probably a good place to start for this is the Tree Widget in
   Doug Young's book "X Window Systems Programming and Applications with Xt"
   (there's also a Motif version) published by Prentice-Hall.
   You could implement the algorithm recently published in July's edition of
   IEEE Software: "Drawing Dynamic Trees" by Sven Moen.  Then you could also
   give it away 8-}.

---

A couple of common things to note:

1) The Form widget has a bug in it such that changes to constraint resources
   on children do not cause the parent to re-layout them immediately.  This
   re-layout can be forced by unmanaging and them re-managing the changed
   child.

2) The Viewport widget will not let the child (in this case a Form) scroll
   itself.  Thus changes in the x and y positions of the child are refused.

---

Richard Hesketh   :   @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk
		  :   rlh2@ukc.ac.uk    ..!{mcsun|mcvax}!ukc!rlh2
Computing Officer, Computing Lab., University of Kent at Canterbury,
Canterbury, Kent, CT2 7NF, United Kingdom.
        Tel: +44 227 764000 ext 7620/7590      Fax: +44 227 762811