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

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!

Regards,

Tatiana

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

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,

Tatiana

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.

Wolfgang

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...

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...

Tatiana

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

Thomas

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!

Tatiana