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