Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!decwrl!asente
From: asente@decwrl.dec.com (Paul Asente)
Newsgroups: comp.windows.x
Subject: Re: XtSetValues / geometry_manager problem
Message-ID: <789@bacchus.dec.com>
Date: 21 Sep 88 18:19:38 GMT
References: <6365@batcomputer.tn.cornell.edu>
Distribution: comp
Organization: DEC Western Software Lab
Lines: 26

In article <6365@batcomputer.tn.cornell.edu> gdykes@batcomputer.tn.cornell.edu (Gene Dykes) writes:
>1) How is a geometry manager supposed to make a good layout when it is given
>Widget and constraint values which point to outdated information?

In order to make a decision, it has to have both the old and the new
values.  The old values are in the widget, and the requested new ones are
in the request.  The geometry manager gets passed the widget with
everything updated *except* the geometry fields -- these haven't really
changed until the geometry manager says they can be.  All constraint
fields the geometry manager gets have been updated.  (This is definately
true in R3; I don't remember for sure if it is true in R2).

>2) A GeometryManager may also be affected by certain constraints of a widget.
>If one of these constraints is changed by XtSetValues, there is no mechanism
>for telling XtSetValues that the geometry manager needs to be called.

Yes, this is a real problem.  I solved it in a constrained widget I wrote
by having the constraint set_values procedure put unlikely flag values
into x and y and having the geometry manager test for them.  Yes, it's a
hack, and it will fail if you try to move the subwidget to x,y = -6265,
-6265.  Having set_values and constraint set_values return a value saying
to call the geometry manager would have been a good idea, but it's too
late to do anything about it now.

	-paul asente
	    asente@decwrl.dec.com	decwrl!asente