Uniface 9.3 Access key not working like it used to in Uniface 7.2

Author: tatiana@ca.ibm.com (tandron)


We have migrated our application from U7 to U9 and have this pesky problem with one of the forms: ALT+R (which used to start the logic to execute what we call "Retrieve form action", now has no effect. But this only happens when we first open first another , exit it and then open this one. The two forms are unrelated, both are called from athe same "'home" form, which has buttons to call a number of forms. Further more, the French version of the form, which uses ALT+T for the same retrieve form action, opens the Text menu instead. I've been able to circumvent the issue by changing the underlined letters (access keys) in the label, but I don't understand why the problem is happening (no conflict with other access keys, cursor in unifield fields - none of the knows causes seem to apply). Any insight much appreciated.



  1. uniface has more ways to define the "access Keys":

    - look in the ini-File of the application + usys.ini: you will find a section "accelerators"

    - The Keyboard Translation table, has possibly some settings on this key-kombinations.

    - And the Access-Definition in the Menu and/or on the Buttons.

    I don't know, how uniface reacts if there is a conflict in the definitions of the Access Keys: What is taken first, or is it random?

    I would guess somewhere here is the reason for the disbehaviour...

    Author: gypsilon (wva@gypsilon.de)
  2. Thank you for your reply. I checked and there is no Accelerators section in the ini file, and nothing related to ALT+R, ALT+T in the keyboard translation table. I cannot see any conflict with another access key for a button or field, hidden or not. But the behaviour for ALT+R is that of a conflict, i.e. nothing happens when pressed. As for ALT+T, it acts as if a T access key was not present. Note that Retrieve is a Uniface reserved word, unlike its French translation Retrouver. This explains maybe the difference in access key behaviour but does not explain the root cause. And, it only happens on one screen. If I avoid this screen and go to the other dozen or so creens that use ALT+R. it works every time. I believe that there is something related to this particular screen, as opposed to a generic setting.

    Still pulling my hair over this...



    Author: tandron (tatiana@ca.ibm.com)
  3. Hi,


    do you check this with the debugger? Does the trigger is called or nothing happens?

    What settings have $variation? Maybe it is changed by proc-code?

    Best regards


    Author: Thomas.Young (thomas.young@young-consulting.de)
  4. Thank you Thomas for your reply. The debugger shows nothing. The trigger is not executed - you just get the bip as if the access key is not assigned. $variation is not changed by proc. But, amazingly, if I swap the Retrieve button with the second button to the right, the access key starts working all right! (instead of having %Retrieve, Cle%ar, ... change to Cl%ear, %Retrieve...). I suspect this has something to do with a reserved word (%Retrieve) being used as label for the first button. It does not make too much sense, why the swapping changes the behaviour especially because the issue does not happen on other screens where Retrieve is the first button too. So I'd still like to get to the bottom of this!



    Author: tandron (tatiana@ca.ibm.com)
  5. Hi Tatiana,

    it is the problem with your "%x" on command buttons (Uniface Style) which you can access these with the ALT-x keycombination

     I think the control-buttons have a high priority in the search-order and with a first-match-wins this button is activated.

    Since I encountered that fact, I use only digits on Commandbuttons and do not use digits in Menues etc.

    Success, Uli

    Author: ulrich-merkel (ulrichmerkel@web.de)
  6. Thank you Uli...unfortunately our application standard does not call for numbers as access keys, so we frenquently run into conflicts, expecially when we have menus with many options. But see the reply fromm Wolfgang - the workaround worked!





    Author: tandron (tatiana@ca.ibm.com)
  7. Hi Tatiana,

    I do not see any reply from Wolfgang with a workaround, but from your following post I assume it is:

    add a dummy button in front of your ones, if the second button onwards works properly.

    Success, Uli



    Author: ulrich-merkel (ulrichmerkel@web.de)
  8. Thank you Wolfgang for the idea...I don't know why I can't see the message in the folder. Removing NED attribute did not make a difference. So I painted a dummy button as the first one and ...hallelujiah!...now works fine. We can not load the latest patch right now because UAT for our migration was done another patch. Compuware was called a few days ago but the tricks we tried (including Ret%rieve) with them did not work as well as this one.


    Thanks & regards,


    Author: tandron (tatiana@ca.ibm.com)
  9. Welcome...

    Sorry, I deleted my reply per accident.

    So again, for others:

    This seemes to be a uniface-bug of a quite early version9-Version. Uniface does not handle the first painted field of an entity correct, "under specific circumstances".

    We had the case, that setting to HID, DIM, YED, YDI ... via Proc was not handled correct from uniface.

    Workaournd: Painting a hidden dummy-Field as the "first" field in the entity 

    Solution: Getting newest patch.



    Author: gypsilon (wva@gypsilon.de)