jlf@earth.cray.COM (John Freeman) (12/23/88)
Question: Given the following text translation table and arguments
to an AsciiStringWidget, why do I get the *default* Text translation
table? I know this is happening because I do not execute my routine
roll_proc on a newline, and text editing occurs like page 21 of the
Athena Widget manual.
char roll_translations[] = "\
<Key>Right: forward-character() \n\
<Key>Left: backward-character() \n\
<Key>Down: next-line() \n\
<Key>Up: previous-line() \n\
<Key>Delete: delete-previous-character() \n\
<Key>BackSpace: delete-previous-character() \n\
<Key>Linefeed: newline-and-indent() \n\
<Key>Return: roll_proc() \n\
<Key>: insert-char() \n\
<FocusIn>: focus-in() \n\
<FocusOut>: focus-out() \n\
<Btn1Down>: select-start() \n\
<Btn1Motion>: extend-adjust() \n\
<Btn1Up>: extend-end(PRIMARY, CUT_BUFFER0) \n\
<Btn2Down>: insert-selection(PRIMARY, CUT_BUFFER0) \n\
<Btn3Down>: extend-start() \n\
<Btn3Motion>: extend-adjust() \n\
<Btn3Up>: extend-end(PRIMARY, CUT_BUFFER0) \
";
/*
* various declarations here to make it all compile
*/
static Arg roll_arg[] = {{XtNheight,(XtArgVal)50},
{XtNwidth,(XtArgVal)564},
{XtNstring,(XtArgVal) roll_buff},
{XtNlength,(XtArgVal)1024},
{XtNeditType,(XtArgVal)XttextEdit},
{XtNtranslations, (XtArgVal) roll_translations},
{XtNtextOptions,(XtArgVal)scrollVertical|
scrollOnOverflow}};
roll_box=XtCreateManagedWidget("roll_input",asciiStringWidgetClass,
box,roll_arg,XtNumber(roll_arg));kit@ATHENA.MIT.EDU (Chris D. Peterson) (12/24/88)
Using Argument Lists: IMPORTANT - toolkit programmers please read.
Understanding how argument lists work is fundamental to X toolkit programming,
an you must understand them of you are going to have any success with the
X toolkit. Agrument lists consist of name-value pairs, and while the names
are well defined and easy enough to come up with, people have trouble with the
values, so let me state it once again, in the hope that I do not need
to repeat it again 10 times over the next year.
Values passed into a widget through its argument list or set via
XtSetValues(), are not passed through a string converter, this means
that you have to specify the actual value of the item that the widget is
expecting for this resource. Integers must be passed as integers
( 3 not "3" ), Pixel values must be passed as pixel values ( Pixel that
corrosponds to black not the string "black"). Just to keep things
from being dull, if the size of the item that you are passing is larger than
(XtArgVal) then you must pass the item by reference (read: pass its pointer),
Otherwise just pass its value.
A word of caution: When using XtGetValues() the argument lists it expects are
name "address" pairs, rather than name-value pairs.
Some Examples:
Right: XtSetArg(arglist[num_args], XtNwidth, 45); num_args++;
Wrong: XtSetArg(arglist[num_args], XtNwidth, "45"); num_args++;
Right: XtSetArg(arglist[num_args], XtNcolor, BlackPixel(display, scr_num));
num_args++;
Wrong: XtSetArg(arglist[num_args], XtNcolor, "black");
num_args++;
On to the Specific question at hand:
> Question: Given the following text translation table and arguments
> to an AsciiStringWidget, why do I get the *default* Text translation
> table?
[ Table deleted. ]
> static Arg roll_arg[] = {{XtNheight,(XtArgVal)50},
> .
> .
> .
> {XtNtranslations, (XtArgVal) roll_translations},
>
> roll_box=XtCreateManagedWidget("roll_input",asciiStringWidgetClass,
> box,roll_arg,XtNumber(roll_arg));
roll_box=XtCreateManagedWidget("roll_input",asciiStringWidgetClass,
box, NULL, 0);
XtOverrideTranslations(roll_box, XtParseTranslations(roll_translations));
This will leave all the current translations in the text widget, and
override only those that you have specified with new values. The X11R3 Client
"xman" does some overriding of translations if you would like to look at a
real example. If you really want to specify an entirely new translation
table then have your argument list look like this:
XtSetArg(arglist[num_args], XtNtranslations,
XtParseTranslationTable(roll_translations));grunwald@m.cs.uiuc.edu (02/21/89)
In the last version of texx2 I noticed that when the asciiStringWidget that I use for error messages fills up, it doesn't scroll (in part because I don't set the ``point'' or whatever it's called). but one thing I noticed was that when I paged foreward using the scroll bar, it didn't get replotted correctly -- I had to hit control-L for it to replot. On a similar note, how do I determine the width of the scrollbar widgets within a viewport? I think I should use XtGetSbvalues, but I'm not certain and it's unclear how I'm supposed to specify the sub-widgets. texx2 is now at 2.5, with diffs to get from 2.4 -> 2.5. Files are available on expo.lcs.mit.edu:contrib or a.cs.uiuc.edu:pub/TeX This version fixes a replotting problem that occurs when not using backing store when windows are mapped. If you're not using backing store and can, you should -- you can scroll the viewport very smoothly, instead of the jerky motion if it's forced to redisplay.
Erik.Hardy@SEI.CMU.EDU (01/12/90)
We're having some trouble with the R3 Athena text widget. On a Sun 3 (SunOS 3.5 and 4.0.3) and microVAX III (Ultrix 2.2), setting XtNeditType to 2 (Editable) and XtNtextOptions to editable works fine, i.e. I can edit the resultant text field. However, using the same settings on a Sparc (SunOS 4.0.3) or on a VAXStation (Ultrix 3.0) using DECWindows, the text field looks the same but cannot be edited. Further info: I can run my application on the VAXStation and display it on my Sun, and the text widget exhibits the right behavior, so I suspect it's something about the window manager, but I'm stumped. Anyone have a clue? Erik Hardy (erik@sei.cmu.edu) SEI/User Interface Project
klee@chico.pa.dec.com (Ken Lee) (01/12/90)
In article <9001111829.AA12156@gh.sei.cmu.edu>, Erik.Hardy@SEI.CMU.EDU writes: > However, using the same settings on a Sparc (SunOS 4.0.3) or on a VAXStation > (Ultrix 3.0) using DECWindows, the text field looks the same but cannot be > edited. Make sure you set XtNinput to true on your shell widget. ICCCM- compliant window managers require this for top-level windows that want input focus. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee
kochhar@endor.harvard.edu (Sandeep Kochhar) (01/13/90)
Is there any way to modify the translation table of a text widget
(through resources) so that if I select something (e.g. a word by
double clicking), and then type a character, the selection gets
deleted and replaced by the character (similar to macintosh applications)?
I tried the following (which doesn't work, though came close in some ways
especially under R3):
xedit*Text.Translations: #override \
<Key>Right: forward-character() \n\
<Key>Left: backward-character() \n\
<Key>Down: next-line() \n\
<Key>Up: previous-line() \n\
<Key>Delete: delete-previous-character() \n\
<Key>BackSpace: delete-previous-character() \n\
<Key>Linefeed: newline-and-indent() \n\
<Key>Return: newline() \n\
None<Key> : kill-selection() insert-char() \n\
(The last line None<Key> was supposed to do the trick...)
Any help will be appreciated.
Thanks
Sandeep Kochhar
(617) 495-3988 mail: kochhar@harvard.harvard.edu
Harvard University kochhar@harvard.csnet
33 Oxford st, kochhar@harvard.uucp
Cambridge, Ma 02138 kochhar@harvard.bitnetkit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (06/06/90)
> Question: One of the two: "end" (in the arguments), or "length" in the > textblock, seem to be redundant; is that so? If not, what if, > start + length - 1 is not the same as "end"? XawTextReplace not only adds text to the file, but also remove text. The text between "start" and "end" is removed and then "length" characters are inserted from the string into the Text widget. I will refer you to the last paragraph of section 5.4.3 in the Athena Widget docs for details. Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213
arm@sps.com (Annette Myjak) (07/31/90)
Is there a reason why the RETURN key doesn't seem to do anything in a multi-line Motif Text widget? (Specifically, it doesn't cause the input cursor to go to the next line like one would expect.) The documentation indicates that the translation table is set up for RETURN to perform a newline(). Is this a 'feature' or is the documentation misleading and I need to do something else. (BTW, I am using UIL to specify my Text Widget.) Thanks!! annette myjak arm@sps.com
daver@dg.dg.com (David Rudolph) (07/31/90)
In article <258@sps.com> arm@sps.com (Annette Myjak) writes: > >Is there a reason why the RETURN key doesn't seem to do anything in a >multi-line Motif Text widget? (Specifically, it doesn't cause the input >cursor to go to the next line like one would expect.) The documentation >indicates that the translation table is set up for RETURN to perform a >newline(). > I have had this problem in Text widgets which were contained in dialog shells. It seems that when a Bulletin Board is the child of a dialog, it sets all its children's translation's so that the return key activates the default button. To change this, you have to set the translation for the return key AFTER creating the text widget. (UIL alone doesn't seem to be able to do it.) Adding the following lines solved the problem for me. (in declarations) char newTrans[] = "<Key>Return: newline()"; XtTranslations transTable; (after declarations) transTable = XtParseTranslationTable(newTrans); (after creating but before managing text widget) XtOverrideTranslations(textWidget,transTable); ---------------------------------------------------------------------------- David Rudolph | phone: (508) 870-6914 Data General Corporation | email: daver@paint.dg.com or | daver@fs06.dg.com ----------------------------------------------------------------------------