curtiss@truffula.umiacs.umd.edu (Phil J. Curtiss) (01/10/91)
I am trying to set the length resource of the text widget named `value' that is a child of a Dialog widget from the resource file of an application I am writting . I can not seem to specify the appropriate resource. I can specify things like: *priceDialog.label: Item Price: *priceDialog.label.background: black *priceDialog.label.foreground: white which works nicely on the child widget of the priceDialog widget name `label'. However, if I try something like, *priceDialog.value: $ 0.00 *priceDialog.value.length: 10 there does not seem to be any effect. That is to say that the user can type in more than 10 characters in the value part of the dialog. Ultimately, I am looking for a way of restricting the number of characters a user may type into the value part of a dialog widget without having to muck around with actions. Any help would be appreciated. Thanks in advance. Phil! -- Domain: curtiss@umiacs.umd.edu Phillip Curtiss UUCP: uunet!mimsy!curtiss UMIACS - Univ. of Maryland Phone: +1-301-405-6744 College Park, Md 20742
curtiss@truffula.umiacs.umd.edu (Phil J. Curtiss) (01/11/91)
After investigating this some more, it appears that the Athena Dialog widget
sets the resource useStringInPlace to FALSE when it creates its AsciiSrc. It
also appears that one can not change the useStringInPlace resource after
an AsciiSrc has been created for the Text widget. Further, the Length resource
has no effect unless the useStringInPlace resource is set to TRUE.
Does anyone know of a work around for this (outside of rewriting the
Dialog widget itself) or can confirm that this is true or not?
On a larger note, what I have done is to create a number of Dialog
widgets and arranged them in a fill-in-the-blank style. However, while
entering data into this fill-in-the-blank form, I have to keep moving the
mouse pointer into the different Dialog widgets to move the keyboard focus to
the Dialog in which I wish to enter data.
Is there a way to make the keyboard focus move to the next Dialog
widget when a key is typed (like a return or arrow key)? Possibly by moving
the mouse to the XtN{x,y} location of the next Dialog widget?
How do other people design entry forms and deal with this problem?
Any help is appreciated. Thanks.
Phil!
--
Domain: curtiss@umiacs.umd.edu Phillip Curtiss
UUCP: uunet!mimsy!curtiss UMIACS - Univ. of Maryland
Phone: +1-301-405-6744 College Park, Md 20742morreale@bierstadt.scd.ucar.edu (Peter Morreale) (01/12/91)
In article <CURTISS.91Jan10153624@truffula.umiacs.umd.edu>, curtiss@truffula.umiacs.umd.edu (Phil J. Curtiss) writes: > > Does anyone know of a work around for this (outside of rewriting the > Dialog widget itself) or can confirm that this is true or not? Can't help you with this, never used a dialog. I create my forms by placing a label and text widget in a form widget. Then I manipulate the form as a whole. (which is probably exactly what a dialog is anyway...*-) > > Is there a way to make the keyboard focus move to the next Dialog > widget when a key is typed (like a return or arrow key)? Possibly by moving > the mouse to the XtN{x,y} location of the next Dialog widget? > > How do other people design entry forms and deal with this problem? > What I did was to register a translation for the associated text widgets and use "XWarpPointer()" to move the pointer upon the user hitting RETURN. I can send code upon request.... -PWM -- ------------------------------------------------------------------ Peter W. Morreale email: morreale@ncar.ucar.edu Nat'l Center for Atmos Research voice: (303) 497-1293 Scientific Computing Division Consulting Office ------------------------------------------------------------------
dshr@eng.sun.COM (David Rosenthal) (01/12/91)
> > > > Is there a way to make the keyboard focus move to the next Dialog > > widget when a key is typed (like a return or arrow key)? Possibly by moving > > the mouse to the XtN{x,y} location of the next Dialog widget? > > > > How do other people design entry forms and deal with this problem? > > > > What I did was to register a translation for the associated text > widgets and use "XWarpPointer()" to move the pointer upon the user > hitting RETURN. > Section 6.2 of the ICCCM says "In general, clients should not warp the pointer". More specifically, Section 4.2.7 says "Clients should not warp the pointer in an attempt to transfer the focus; they should set the focus and leave the pointer alone". The section then goes on to explain how to set the focus. Section 4.1.7 gives more details. David.
acs@pccuts.pcc.amdahl.com (Tony Sumrall) (01/12/91)
In article <CURTISS.91Jan10153624@truffula.umiacs.umd.edu> curtiss@truffula.umiacs.umd.edu (Phil J. Curtiss) writes: > Is there a way to make the keyboard focus move to the next Dialog >widget when a key is typed (like a return or arrow key)? Possibly by moving >the mouse to the XtN{x,y} location of the next Dialog widget? I had the same problem with multiple text widgets in a shell widget. What I ended up doing was: * monitor FocusIn events to the shell widget and grab the focus, * monitor FocusOut events of the shell and ungrab the focus, * for each text widget, set up translations for Return and Tab which will cause it to invoke an action routine to move the focus to the "next" widget. I did all of this with the assistance of Wcl but you can certainly do it "manually". I dunno if this is a "good" way to do it but it works! >Domain: curtiss@umiacs.umd.edu Phillip Curtiss > UUCP: uunet!mimsy!curtiss UMIACS - Univ. of Maryland > Phone: +1-301-405-6744 College Park, Md 20742 -- Tony Sumrall acs@pcc.amdahl.com <=> amdahl!pcc.amdahl.com!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]