Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!rutgers!mit-eddie!xn.ll.mit.edu!hsdndev!bunny!krs0
From: krs0@gte.com (Rod Stephens)
Newsgroups: comp.windows.x.motif
Subject: Re: Pain resizing XmPanedWindowPanes
Message-ID: <10983@bunny.GTE.COM>
Date: 12 Apr 91 11:35:34 GMT
References: <10969@bunny.GTE.COM> <4519@gmdzi.gmd.de>
Organization: GTE Laboratories, Waltham MA
Lines: 32

In article <4519@gmdzi.gmd.de> berlage@gmdzi.gmd.de (Thomas Berlage) writes:
>Geometry requests like this not only go to the paned window. The paned
>window itself must check with its parent whether resizing the whole
>paned window is OK. In this case, you probably need to set
>XmNallowShellResize of the nearest shell ancestor to True. There may
>even be other manager widgets in the hierarchy that can prevent resizing.
>
>Thomas Berlage (berlage@gmdzi.gmd.de)
>GMD, Sankt Augustin, Germany

Yes! Perfect! The XmPanedWindow was trying to resize itself
to accomodate the pane's resizing and its ancestor was not
allowing it. Setting XmNallowShellResize did the trick.

What I expected it to do was to resize one pane at the
expense of the others, just like it does when the user drags
a sash. This would not require the XmPanedWindow to resize
so XmNallowShellResize would not be a problem.

Now the bonus question: Is there a way to get this to
happen? In particular, is there a way to make the
XmPanedWindow save up child resizes and do them all at once?
Then I could grow window 1 and shrink window 2 by the same
amount to get the desired effect. (When I do this now there
are ugly redrawing effects.)

+---------------------------------------------------------------+
| Rod Stephens           | "Haven't I told you not to play      |
| GTE Laboratories, Inc  |  with my super-weapons? You might    |
| (617)466-4182          |  devastate yourself!"                |
| krs0@gte.com           |                                      |
+---------------------------------------------------------------+