The user is familiar with pressing a function key anywhere on the IBM i and expects a corresponding function to be executed if it is stored in the corresponding program.
This can even be done in relation to the current cursor position. In a typical Windows program this works differently. Here, the developer of the interface has to explicitly worry about whether and what happens when a function key is pressed.
Under Windows there is no longer an absolute cursor position outside of special controls (e.g. input fields, documents). Instead, the current focused control is responsible for handling keystrokes. Only certain keystrokes are processed by the operating system by default (e.g. cursor keys, Tab, Alt+F4).
Keys on different controls also trigger different actions. Pressing the Enter key in an input field has no effect (or leads to a line break). If, on the other hand, you press the Enter key on a button, the click event is triggered.
iNOW OnTheFly Mode
As long as a screen is not designed, it is in emulation mode (OnTheFly mode). Here the behavior of the IBM i is emulated as far as possible.
iNow UI and INow AOF
If you redesign a screen, then you are in the difficult situation of, on the one hand, ensuring typical Windows operation and, on the other hand, not completely frightening the familiar IBM i user and enabling him to use the keyboard as familiarly as possible.
iNow UI standard implementation
Since there is no cursor position under Windows any more, this is lost at first and must be mapped by other mechanisms. The iNow standard input fields therefore remember their “original position” and send it e.g. when pressing function keys. Other controls pass on function keys without special position specifications.
Windows standard controls, such as a simple button, do not pass on any action status entries; here you yourself are responsible for the corresponding forwarding or processing.
What does this mean for the designer??
If, for example, you store additional standard buttons, then of course you have to decide for yourself what should happen when you click. In the associated click event, you can, for example, send a function key to the host.
SendKey(FlexHostKeys.F4, x, y);
This is not very surprising, but something else is interesting:
If you now switch to the button with the Tab key so that it has the focus, you can trigger the click with the Enter key, for example. Ok, you certainly expected that too
If you now press F4 or PictureUp/PictureDown, then … NOTHING
The IBM i user would have expected this key to be sent to the host in the same way as if it were on another iNOW input field.
Since the default button now has the input focus, it determines what happens when keyboard input occurs. Since it doesn’t know anything about an IBM i, nothing happens. So you have to teach him to pass on the keys.
For this you append a new event
KeyDown and insert the following line of code into it:
Alternatively, you can also add parameters to this call
ML.HandleKeyDown(this, e, true, true);
With the first additional parameter you determine whether the PageUp/PageDown keys should be ignored, with the second parameter you can ignore the Enter key.
Of course you can also simply use a
FlexSpeedButton, this will do it automatically for you