mls@cbnewsm.att.com (mike.siemon) (03/07/91)
> I am using textfield widget of openlook intrinsics > toolkit. What I want to do when ever pointer is in the field > and if user presses any key widget should call application > supplied function. > As you know textfield widget doesn't offer any call back of > that kind. So I tried to solve this problem by to different > methods. Yes, the TextField widget doesn't directly provide this callback. However, it uses the TextEdit widget, and that widget provides this callback (XtNkey). The TextField's XtNtextEditWidget resource provides a handle to the TextEdit widget. NOTE: This assumes you are using the OLIT toolkit from Sun's OpenWindows 2.0 product (or later). If you are using an earlier version of OLIT, the TextField widget uses the older Text widget, which doesn't have the XtNkey resource. You'll have to use the event handler or translation table method you tried (see below). > I used XtAddEventHandler() [on the TextField widget] .... The TextField widget is a composite, as suggested in my paragraph above. Thus the window of the widget on which the event handler is registered will not be getting the events, rather the window of the TextEdit widget (or Text widget, for older versions) will get the events. Place the event handler on the child widget and this should work. NOTE: If you are using the older toolkit, you will have to fetch the Text widget ID by examining the children list of the composite instance record...ugh! We should have made the TextField a subclass of TextEdit, not a composite that creates a TextEdit child. Sorry! > What I expected, while pointer is in the text field, when > user presses any key myhandler() will be called. Somehow it > does not do anything like that. Also, make sure you are operating in a focus-follows-pointer mode. If not, you must first click in the window to move focus to the widget. Without focus in the widget, keyboard events will not go anywhere near the TextField widget (or its child). > 2- I modified widget's translation table. > .... > Resource table for 2nd method: > *label:File Name: > *textfield.translations: #override\n\ > <Key>:myfunc() Again, the child of the TextField widget is the one getting the keyboard events, so it must have its translation table modified. The name of this child is "Textedit" (another mistake, we didn't follow widget naming conventions--should be "textedit" or "textEdit"). > I was reading openlook GUI RM it says in the core widget's > resources that application should not change > XtNtranslations. One thing surprise me that unlike motif, > openlook toolkit documentation does not provide info. about > the default translation table of its wiget set. Does it mean > we should not modify wigdet's translation table? For most widgets this is deliberate, because we are trying to give application USERS a consistent interface across diverse applications. Thus we provide high-level callbacks for widgets like buttons, scrollbars, scrolling lists, etc. Even for text widgets we provide high-level callbacks so that most applications can simply fetch text from the user, thereby providing a consistent text-input interface. However, text input needs are also a highly variable, and we recognized that we can't constrain application developers too tightly here. Thus the XtNkey callback on the TextEdit widget. It is a reasonable request that the translation tables be advertized for at least the more important widgets, such as the TextEdit (and TextField, if we ever make it a subclass of TextEdit!) Steve Humphrey UNIX System Laboratories merlyn@attunix.att.com