spa%hara.fctunl.rccn.pt@MITVMA.MIT.EDU (Salvador Pinto Abreu) (09/03/88)
Could someone help me with this one?
I have a group of Command widgets setup with:
XtSetArg (args[n], XtNwidth, 70); n++;
at XtCreateManagedWidget() time. The purpose is to have a set of
buttons all the same size, which looks nicer. The Command widgets are
children of either a Form or a Box widget.
A little later, I try to make the widget insensitive, by calling:
n = 0;
XtSetArg (args[n], XtNsensitive, 0); n++;
XtSetValues (b, args, n);
The "sensitive" bit works fine, but the button shrinks down to its
minimum size. I tried:
n = 0;
XtSetArg (args[n], XtNsensitive, yes); n++;
XtSetArg (args[n], XtNjustify, XtJustifyLeft); n++;
XtSetArg (args[n], XtNwidth, 70); n++;
XtSetValues (b, args, n);
To no avail. Is this a bug? Am I doing something wrong?
---
Salvador Pinto Abreu BITNET/Internet: spa@hara.fctunl.rccn.pt
or: FCT_SPA@PTIFM.BITNET
UUCP: ...{mcvax,inria}!inesc!unl!spa PSI/VMS: PSI%(+268)05010310::SPA
ARPA: spa%hara.fctunl.rccn.pt@mitvma.mit.edu Phone: (+351) (1) 295-4464 x.0560
Snail: Dept. de Informatica, Universidade Nova de Lisboa
2825 Monte Caparica, PORTUGALswick@ATHENA.MIT.EDU (Ralph R. Swick) (09/04/88)
Date: Fri, 2 Sep 88 19:22:56 GMT
From: spa%hara.fctunl.rccn.pt@mitvma.mit.edu (Salvador Pinto Abreu)
I have a group of Command widgets setup with:
XtSetArg (args[n], XtNwidth, 70); n++;
[...]
A little later, I try to make the widget insensitive,
[...]
The "sensitive" bit works fine, but the button shrinks down to its
minimum size.
[...]
Is this a bug? Am I doing something wrong?
This is not a bug, though enhancements to the implementation may be
desireable. Command is a subclass of Label and Label _always_ asks
it's parent to resize it to it's preferred geometry on a SetValues
request, unless it perceives that a specific geometry _different from
it's current geometry_ was also requested. If the parent is Box,
the resize will usually be permitted. If the parent is Form, the
'resizable' constraint resource specifies whether or not Form grants
the resize request.rlh2@eagle.ukc.ac.uk (Richard Hesketh) (09/04/88)
In article <8809021922.AA22023@hara.fctunl.rccn.pt> spa%hara.fctunl.rccn.pt@MITVMA.MIT.EDU (Salvador Pinto Abreu) writes: >Could someone help me with this one? > I'll try. >..... The purpose is to have a set of >buttons all the same size, which looks nicer. The Command widgets are >children of either a Form or a Box widget. > Fine, except you must remember that these widget classes have geometry managers, which are not to put too fine a point on it, primative. They will get better I am sure. By default they let the child have its own way. >A little later, I try to make the widget insensitive, by calling: > ... >The "sensitive" bit works fine, but the button shrinks down to its >minimum size. I tried: > ... Ah ha. This is because the label part of the command widget asks (during the set_values procedure stage) its parent if it can be its preferred size by making a geometry request. Now because this request is smaller than the size you forced it to be, the parent geometry manager gives the ok and the command widget shrinks... > >To no avail. Is this a bug? Am I doing something wrong? It is not really a bug, just a minor irritation. You just need to get the geometry manager to not allow the child to be resized. With the Form widget this can be achieved using .. XtSetArg(args[i], XtNresizable, FALSE); i++; XtSetValues(cw, (ArgList)args, i); (note: cw is the command widget) However the parent only uses this for geometry requests and will override the size of its children if it is resized. The Form also uses integer division when resizing and therefore gets truncation errors, yuk. Also if the widget is shrunk then the label part of the widget doesn't bother to reposition the label within this new size, now that is a BUG. The Box widget thinks it knows best and colludes with its children so the application doesn't get a look in. My advice is to stick with the Form widget or like me, write a better one. >Salvador Pinto Abreu BITNET/Internet: spa@hara.fctunl.rccn.pt Richard -- Richard Hesketh : rlh2@ukc.ac.uk ..!mcvax!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, England.
jensen@gt-eedsp.UUCP (P. Allen Jensen) (09/06/88)
I have two scrollbar widgets. The first controls the starting point
in a set of samples and the second controls the number of samples.
I am trying to change the size of the Thumb in the first widget in
response to the position of the second widget.
When I try to create the widgets with values for XtNtop and XtNshown,
the values set are ignored.
It would appear that there are certain times when certain values cannot
be set/changed in several widgets. There also seem to be some problems
in leaving default values alone or changing them at certain times. If
someone could provide some more complete documentation on the various
widgets, it would be greatly appretiated.
P. Allen Jensen
--
P. Allen Jensen
Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332-0250
USENET: ...!{allegra,hplabs,ihnp4,ulysses}!gatech!gt-eedsp!jensen
INTERNET: jensen@gteedsp.gatech.edubobmi@hpcvlx.HP.COM (Bob Miller) (09/06/88)
You could use HP's public domain widget library. (It will be on the R3 tape and is also available electronically from MIT now-- a note was posted on exactly where it can be obtained a week or so ago). All of the primitive widgets (buttons, static text and raster) have a resource (XtNrecomputeSize) which when set to FALSE will prevent the widget from changing size in response to a XtSetValues.
ike@PLANCK.STANFORD.EDU (Ike van Cruyningen) (09/08/88)
In article <8809021922.AA22023@hara.fctunl.rccn.pt> Salvador Pinto Abreu writes > The purpose is to have a set of buttons all the same size, > which looks nicer. I have created a subclass of the Command widget class which takes an additional resource flag `noResize'. When this flag is on, the widget will not try to resize itself, though it will still respond to resize commands from the parent. This widget class is normally part of the WidgetMaster package. At the core of the WidgetMaster package is an interpreter which will take a data file of widget specifications, and produce the user interface on the screen. Specifying widgets and their resources in a data file eliminates the repetitive coding of ArgLists, CallbackLists, resource converters, and other widget creation code. It also makes changes to the user interface much easier, as you simply edit the data file and rerun the application - no recompilation is required. If you would like the code for the subclass of the Command widget class, please send me E-mail and I will get it out to you. If you would like more information on the WidgetMaster package, please let me know. Ike van Cruyningen Stepping Stone Software 195 Oak Grove Road Menlo Park, CA 94025 415-329-9816