I return to this old topic because what I want to ask is related. Even perhaps solved elsewhere.

As always, my clients are accustomed to ENTER or DOWN ARROW to advance, and ESCAPE or UP ARROW to step back. If I now propose to use TAB and SHIFT-TAB, I'm thrown by a balcony.

So the first thing I did when I started with HMG is a function that avoids using the TAB key, allowing the user to move from the keyboard "as God commands".

But I have a problem: if I open the same program three times and play with it on the screen, passing from one window to another, there comes a time when the function I mentioned is lost. But the most curious thing is that I follow and recover it after x? movements. I have not found a logic to that disconnect-connection.

The question would be: when or how does a key lose its assigned function?

If I understood well you are trying to imitate old DOS behaviour? (In order NOT to get thrown from a balcony... or worse).
I once also had to convert an old Clipper app with keeping the same screen behaviour: this do-able but not desirable. You will have to use a lot of coding (which has nothing to do with the original functionality of your app) which makes it all hard to maintain and debug.

When users are common to old app's they don't really want to change their habits. Example: they know all kinds of input-codes by heart and don't want to use listboxes or comboxes (which are pre-filled with the possible options).

Maybe you can convince them to try and let them discover the new possibilities.

Your help has been very useful because it has allowed me to know where is not problem. This function KEYSALIR() works well within a group of textbox, as we have both been able to verify, and in both W7 and W10 ... provided there are no other things in between.

I think I have located where the mismatch occurs: it is a textbox that asks the NIF (tax identification number in Spain) and calculates the control letter that completes the data. I have not had time to do tests yet, but it should be there. The strange thing is that it does not affect the window where it is working, but to others that are open, even if it is Notepad++, where also the arrow keys become silly.

As for changing the action of certain keys would occupy many lines of code, I do not agree. I use a general .PRG (as a .CH file) for all applications, where I include this kind of thing. You see: shorter KEYSALIR() than SET NAVIGATION EXTENDED.

Initially I was also thinking of providing the same screen effect from the good old DoS screen.
However later I had realized that GUI users don't care about the old screens. They will change to the new screen without any problem.
On the other hand, I also welcome if it is possible to maintain the old screen layout and functionalities it is an added advantage.

I agree with this last one that you say, as long as there is no conflict, that each one use the key that prefers to advance or back.

But I do not agree with what you say before, my admired Rathinagiri.

For me there are no GUI users and console users. There are jobs and jobs. And each type of work requires a suitable tool. The user must judge, never a developer locked in his study, because what is theoretically good, in practice may be useless.

A real example: an administrative who every afternoon devotes an hour to making invoices, and in that time he makes about fifty. The references are not many (it's a cheese factory) and are well coded, so that it practically works with one hand, the right, "spilled" on the numeric block, INTRO and arrows. It does so at a dizzying speed. If to move between the different fields had to use TAB and SHIFT-TAB, it would lose much operability.