| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2008.1 | | LEOVAX::TREGGIARI | | Mon Jan 08 1990 10:54 | 13 |
| From looking at the code, an XtSetValues on the DwtNorientation of a menu
should be enough to cause it to re-layout its children. This should happen
regardless of any geometry "negotiations" that need to take place (i.e. even
if it doesn't change size, the children should be layed out differently).
As far as the geometry negotiations go, the menu widget will make a request
to change size. That has to be "approved" all the way up the widget hierarchy
for it to take place. That is, the dialog_box has to be willing (it will
be unless it has been defined to be "fixed" size), and then whatever is
above that (shell widget?). The top-level shell must have the
resource XtNallowShellResize set to TRUE, or it won't allow the resize.
Leo
|
| 2008.2 | | UKEDU::DDAVIES | A Dolby gas fire ...no problem. | Mon Jan 08 1990 16:10 | 19 |
| Thanks for your thoughts.
I have XtNallowShellResize on toplevel, DwtResizeShrinkWrap on the dialog_box,
and I've tried every combination of DwtNresize on the dialog_box and
DwtNMenuPacking on the work_area_menu.
Having done a XtSetValues to change the orientation of the menu nothing
happens, but when I make a change to the label of one of the menu's buttons
it triggers the menu to horizontal but with the height of each button the same
dimension as the original vertical menu (i.e. huge buttons).
XtSetting to vertical again has no effect until I "do" something to one of
the menus buttons but now the button width stays the same as the "huge button
horizontal menu" i.e. I now have huge long thin buttons in a vertical menu.
The bottom line is I suppose that nothing happens on just a XtSetValues of the
orientation of the menu. I've tried XSynchronize just incase it was some
buffering problem.
-dave
|
| 2008.3 | sounds familiar | WAIT::DESAI | Jatin Desai | Mon Jan 08 1990 16:37 | 7 |
|
I remember a problem with menu widget (V1) not re-sizing properly after
changing the orientation. The workaround was to set the menu width/height to
be zero whenever you change the orientation. I am not sure if this bug is
still there and is one of the causes to your problem though.
Jatin
|
| 2008.4 | that got it! | UKEDU::DDAVIES | A Dolby gas fire ...no problem. | Mon Jan 08 1990 16:54 | 8 |
|
XtSetValues width/height = 0 did the trick.
I am still on V1 (must get around V2).
Is it correct to expect XtSetValues to trigger all the necessary layout,
geometry, resize code ?. i.e The widget USER doesnt have to use some
other Xt to trigger "negotiations" ?
-dave
|
| 2008.5 | Correct | LEOVAX::TREGGIARI | | Tue Jan 09 1990 07:43 | 7 |
| > Is it correct to expect XtSetValues to trigger all the necessary layout,
> geometry, resize code ?. i.e The widget USER doesnt have to use some
> other Xt to trigger "negotiations" ?
Yes, that is correct.
Leo
|
| 2008.6 | there's more | UKEDU::DDAVIES | A Dolby gas fire ...no problem. | Wed Jan 10 1990 06:16 | 18 |
| Something else along the same lines...
I'm generally concerned that XtSetValues does not seem to do all it should.
(or, I suppose, all I THINK it should)
eg. CommandWindow widget.
Hi level convenience functions like DwtCommandSet end up doing an
XtSetValues of the DwtNvalue of the widget ? and nothing extra ?
Thing is I can DwtCommandSet ok but XtSetValues of DwtNvalue does nothing.
Also when I XtSetValues of DwtNprompt then the prompt changes BUT the size
of the previous prompt limits the amount of the new prompt thats visible.
i.e. the resize/layout/geometry question again.
Keep talking.
-dave.
|