Obtaining the key pressed in an editBox

Hi Rob,

Short answer: what about mapping Enter to NEXT_FIELD in your keyboard translation table?

Long answer: Uniface is not real time oriented and it does not propose such functionality; nevertheless there are tricks to be put in place like a single character field with autojump and start_mod trigger that can simulate what you are asking for; probably long time Unifacers can propose many others.
Using one of these tricks or not depends from real meaning of what you are trying to achieve.
Probably a more detailed description of your scenario could help.

Gianni

Hi Rob,

Workaround :

1) draw a control button with properties Role=Default (it will be activated by pressing the enter key)

   You can also hide it with HID .

    In the trigger detail, test the current fieldname ($fieldname) to do a specific proc.

2) Use the extented trigger OnEdit (with the properties Onedit=true uniface 9.6.4) , if the value has not changed when the trigger is triggered, you may be able to consider pressing the enter key.

Gilles.

Giles,

  Thanx for the response!

1) I tried that initially and it does work if HID is not used.  If HID is used, the detail trigger doesn't appear to fire.  I've gotten around this by changing the button size properties programmatically to 0,0 (in effect, hiding the button).  However, if split bars are ever added, this will fail.  Also, $fieldname always returns the name of the button and the user will lose their focus if pressing enter elsewhere because the hidden button gets focus when enter is pressed.

2) I will review this option but I don't want to update the form on every change to the field since quite a bit of information is updated when the field is changed.  Ideally, I'd like to validate the field upon completion of the change and then perform an update.

Gianni,

  Thanx for the reply!

If I could map Enter to NEXT_FIELD for this one form that would probably work.  Since this is an MDI app,that could cause confusion on other open forms when navigating away and back to this form.  I suppose I could make the form modal, but I'd limit functionality for the user base.

I provided a bit more info on the form in my reply to Giles.  I'll keep plugging away!

Hi Rob, 

We put the following line in our keyboard translation table

^136^CR			^USER_KEY^065

This means the keypad enter key fires the Userkey trigger on the form, and you can then code for action based on $fieldname in there. 

regards, 

Iain

Thank you all for your suggestions.  This seems to work best for me:

Define Button (Change geometry to size 0, 0) to "hide" it but let it remain active:

$PaintedFieldProperties("ButtonName.EntityName", 1) = "xSize=0·;ySize=0"

Detail Trigger in  "hidden" button:

DoFormUpdates()

$FieldProperties("ButtonName.EntityName") = "Role=Normal"

Field Get Focus trigger for field to be modified:

$FieldProperties("ButtonName.EntityName") = "Role=Default"

I understand split bars will nullify the geometry but it's a safe bet this form won't need it.

Hi Rob et al.,

there is a very old trick to keep the effect of the modified keyboard "local":

In the field gets focus set $keyboard to the "keybord_with_enter"
(you may want to save old $keyboard to a $$variable for the reset).

in the complementary looses focus reset $keyboard to the standard one.

Have some fun,
Uli

Edit:

We can even work more local  when our KTT activates "^HELP".
So we only have to concentrate on field related triggers:
field gets focus: set $keyboard to the modified keyboard
field help: performs whatever is requested when the user press ENTER
leave field: set $keyboard to the standard keyboard ($$keyboard saved in aplication execute).

As we can do all this in the modeled entity, this reduces modification overhead,
Uli

Hi Rob,

Ok.

For the first case , Do you define the button with characteristics "control"  ?