Conference bulova::decw_jan-89_to_nov-90

> What is the correct translation for this key.

KP_Enter should do it.

> 2) question  : I have to define several control-characters for this input-line.
> I would like to define them all in my translation table and then just use a 
> switch-statement to do the appropriate action.
> How do I get the character which invoked the translation in the actual routine ?

I don't think the R3 Intrinsics will allow you to get at that information.
In R4, there is a new routine (XtGetActionKeysym) which will do this.
One thing you can do now, is pass a paramter into the action routine
to distinguish which line invoked it.  You can do something like:

char pinputTranslations[] = 
"<Key> Return: pinput(1) \n\
 Ctrl<Key>J  : pinput(2) \n\
 Ctrl<Key>M  : pinput(3)"

The parameter value is passed into the action routine (in string format).

Leo

So far so good. Now I am having problems adding the tab-key which is normally 
used to switch between your different simple text widgets. Neither 
XK_Tab nor XK_KP_Tab seems to work; 

Of cause, once this problem is solved, I would like to move the input-focus
from my program. How do I do this? Extract the function from the old translation
of the Tab-Key before I redefine it?

Or do I have to write my own widget for all that.

Any help is highly appreciated


Mike

> Now I am having problems adding the tab-key which is normally
>used to switch between your different simple text widgets. Neither 
>XK_Tab nor XK_KP_Tab seems to work;

Mike,

I thought your project was moving towards Motif?
Why all this Xlib hackery? ;-)

XmAddTabGroup() will allow you to traverse through a widget
hierarchy with the keyboard.  Full keyboard functionality is one
of Motif's biggest assets...why not use it?

#include <Xm/Xm.h>

	void XmAddTabGroup (tab_group)
		Widget       tab_group;

[AddTabGroup adds a Manager or Primitive widget to the list of tab groups
 associated with a particular widget hierarchy....you should not mix widgets
 associated with different tab groups.  In your case, it is only text widgets]

Stop by if you want to see how it works.

Kris..

Also we want to convert to Motif eventually, we have to wait until Motif is
official for Ultrix AND VMS. Also DecTrade is not written in Motif and it would
look ugly (for customers anyway) to have 2 different User-Interfaces on 
the screen.

But this would not solve my problem anyway. I don't want to add another group
to the widget hierarchy, I don't want to traverse at all. I want to attach a
callback function to the Tab-Key as I do it with other control characters.

This simple-text widget has to emulate a TELERATE-Terminal and the Tab-Key
is used to issue different Mode-Commands.

Anybody got more ideas how to solve this ???


Mike

Hopefully, I can help, but I need some more information first.  First, what
is the widget hierarchy from the shell widget down to the text fields?
Second, without your doing anything with TAB, doesn't the TAB field cause
focus to move between text fields already?

Leo

The simplified Hierarchy looks as follows:
             
	      +--- menu-bar - [pulldown menus]
              |
main-window  -+--- list-box
              |
              +--- attached dialog box - [buttons]
              |
              +--- attached dialog-box -+-- pushbutton
                                        |
                                        +-- simple-text 1
                                        |
                                        +-- simple-text 2

It is correct that the TAB-Key moves between my text-fields, but exactly
this is what I am trying to avoid. I want to leave Shift-TAB to move between
fields and get notified when the user pressed the TAB-key. The TAB-Key should
NOT move between fields. Moving between fields under program-control was the
second question (which is at the moment not so important)

I tracked already the reason down why the Translation manager for the textfields
can't recognize the TAB-Key. The attached dialog-box has this key in
DwtNgrabKeySyms defined. In DwtNgrabMergeTranslations are the functions defined
which move the focus from field to field. I can't find a way to redefine these
attributes in UIL (they can't be changed after creation). I also tried to 
install the TAB-Key as an accellerator, but without success. It seems that the
translations in DwtNgrab* have precedence over the DwtNtranslations.

The problem is that our application MUST use the TAB key (otherwise I would not
go through all this trouble)

I hope this makes more sense now...

Hopefully, there is a solution...


Mike

        I asked about removing the grab using UIL in
        CLT::DECWTOOLKIT note 197 and Leo answered there.
        
>> CLT::DECWTOOLKIT 197.5
>>            Yes.  Add this to the definition of the dialog box.
>>
>>                arguments {
>>                    argument ('grabKeySyms') = 0;
>>                    argument ('grabMergeTranslations') = 0;
>>                };
        
        Dan