ssroy@phoenix.Princeton.EDU (Steve Scot Roy) (03/07/89)
When I try to use the HP text widget I get a problem that I do not
understand.
I can put it on the screen and use it with no problems save two.
The first, and more annoying, is that the keys 'i' and 'd' seem to be
mapped to carriage return and delete respectively.
Second, the caret leaves residues on the left hand edge.
I am using vanilla X11 and Hp widgets on a Sun 3/160 running version
3.?, patches 1-8 for X11 and a set of patches for the widgets that
claim to make it compatible with X11. I don't remember the origin of
those patches, but they came off the net into a file called Xw.R3fix.tar.
Everything compiled without errors.
Also, the programs in the test directory do not all compile, and the
ones that compile do not all run. Several complain about missing a
routine XtGetCursor, several die on execution with a Segmentation
Violation when the cursor moves into the window. All of the major
problems I can remember for these tests seem to deal in some way with
the cursor.
Also, the code in the Xt directory in the Xhp distribution will not
compile. Is it for release 2 of X?
Has anyone else had these problems? Is there a new version or bug fixes
around? Should I look to Xt or to Xw for the problems?
ssr@courant.princeton.edu
Here is the code, it is obviously hacked from one of examples.
#include <stdio.h>
#include <X11/StringDefs.h>
#include <X11/Intrinsic.h>
#include <Xw/Xw.h>
#include <Xw/TextEdit.h>
static char default_value[] =
"This is a\ntest. If this\nhad been an actual\nemergency...";
main(argc, argv)
unsigned int argc;
char **argv;
{
static Arg arglist[] = {
{XtNeditType, (XtArgVal) XwtextEdit},
};
Widget toplevel;
char *index();
toplevel = XtInitialize("textTest", "Demo", NULL, 0, &argc, argv);
XtCreateManagedWidget( argv[0],
XwtextEditWidgetClass,
toplevel, arglist, XtNumber(arglist) );
XtRealizeWidget(toplevel);
XtMainLoop();
}mayer@hplabsz.HPL.HP.COM (Niels Mayer) (03/07/89)
In article <6858@phoenix.Princeton.EDU> ssroy@phoenix.Princeton.EDU (Steve Scot Roy) writes: >When I try to use the HP text widget I get a problem that I do not >understand. > >I can put it on the screen and use it with no problems save two. > >The first, and more annoying, is that the keys 'i' and 'd' seem to be >mapped to carriage return and delete respectively. > >Second, the caret leaves residues on the left hand edge. I've noticed the same problems in my applications. I've noticed that the problem goes away if I relink my program with an X11r2 libX11.a. You can also get rid of the problem by changing the defaultTextEditTranslations table in Xw/TextEdit.c or override them via .Xdefaults. I guess that suggests that things have changed in the translation names between r2 and r3. I have a partial clue: from TextEdit.c status --------------- ----------- <Key>InsertLine can't find it in r3 <Key>DeleteChar changed to <Key>Delete (?) What's going on here? I'm so confused! Where's all this documented? Help! I haven't had the time or desire to look into this in more detail... -- Niels. PS: While we're at it, there's also a missing element in the TextEdit class record declaration: *** TextEdit.c Fri Mar 3 14:14:11 1989 --- TextEdit.c.patched Tue Feb 28 21:15:51 1989 *************** *** 2448,2456 /* version */ XtVersion, /* callback_private */ NULL, /* tm_table */ defaultTextEditTranslations, ! /* query_geometry */ NULL, ! /* display_accel */ XtInheritDisplayAccelerator, ! /* extension */ NULL }, { /* XwPrimitive fields */ --- 2448,2455 ----- /* version */ XtVersion, /* callback_private */ NULL, /* tm_table */ defaultTextEditTranslations, ! /* display_accelerator */ XtInheritDisplayAccelerator, ! /* extension */ NULL }, { /* XwPrimitive fields */
alex@otter.UMBC.EDU (alex) (03/09/89)
In article <3032@hplabsz.HPL.HP.COM>, mayer@hplabsz.HPL.HP.COM (Niels Mayer) writes: > from TextEdit.c status > --------------- ----------- > <Key>InsertLine can't find it in r3 > <Key>DeleteChar changed to <Key>Delete (?) > > What's going on here? I'm so confused! Where's all this documented? Help! > I haven't had the time or desire to look into this in more detail... If you remove InsertLine and change DeleteChar to Delete, the problems with 'i' and 'd' go away, but that brings up a more intereting question... What appears to be happening is since the toolkit can't identify "InsertLine" it matches it to "I" without even a warning. I wouldn't expect this, especially in light of the fact that it will produce warnings about multiply decined keys, ie: <Key>I: something()\n\ <Key>InsertLine: something()\n\ produces a warning about a redefined Key! :alex Alex Crain Systems Programmer alex@umbc3.umbc.edu (NEW DOMAIN!) Univ Md Baltimore County nerwin!alex@umbc3.umbc.edu
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (03/09/89)
In article <1770@umbc3.UMBC.EDU> alex@otter.UMBC.EDU (alex) writes: @In article <3032@hplabsz.HPL.HP.COM>, mayer@hplabsz.HPL.HP.COM (Niels Mayer) writes: @> from TextEdit.c status @> --------------- ----------- @> <Key>InsertLine can't find it in r3 @> <Key>DeleteChar changed to <Key>Delete (?) @ @ If you remove InsertLine and change DeleteChar to Delete, the problems @with 'i' and 'd' go away aaaah.. but of course! boy do i feel stupid! @ but that brings up a more intereting question... @ @ What appears to be happening is since the toolkit can't identify @"InsertLine" it matches it to "I" without even a warning. I wouldn't expect @this, especially in light of the fact that it will produce warnings about @multiply decined keys, ie: @ @ <Key>I: something()\n\ @ <Key>InsertLine: something()\n\ @ @produces a warning about a redefined Key! On the other hand, I shouldn't feel that stupid. I'd consider that behaviour to be a BUG, or at least a MISFEATURE. This should be fixed pronto since translationtables are something that USERS might diddle with -- simply mispelling a symbolic keyname in the translationtable would cause the application to just gobble up whatever random character happened to be at the head of the mispelled name. All that, with no warning. Not exactly USER friendly. While I'm complaining, I also think that the actions carried out by matching on a sequence of keys should be independent of the order in which elements of the translationtable are listed -- can't the translation table compiler figure that out? It's incredibly bogus that I can't just append or prepend an arbitrary keybinding to a txlationtable -- the way things are set up, I have to "always put more specific events in the table before more general ones." (Xt Intrinsics doc, p. 128). This can make modifying an existing translation table a nightmare, especially if that translation table is sitting in somebody elses program in a library. -- Niels.
swick@ATHENA.MIT.EDU (Ralph R Swick) (03/09/89)
> @ <Key>I: something()\n\ > @ <Key>InsertLine: something()\n\ > @ > @produces a warning about a redefined Key! > > On the other hand, I shouldn't feel that stupid. I'd consider that > behaviour to be a BUG It is. > , or at least a MISFEATURE. This should be fixed > pronto since translationtables are something that USERS might diddle with It has been (here).