Info{"Keyboard")

Panorama X
1

I want to use Info{“Keyboard”) in a procedure triggered at the ending of data entry to see if the Return key was pressed instead of the Tab. It isn’t working.

2

This procedure worked for me.

if info("keyboard") = tab()
    message "Tab Key"
elseif
    info("keyboard") = cr()
    message "Carriage Return"
else
    message asc(info("keyboard")[1,1])
endif
3

You haven’t indicated WHY you want to determine whether Return was pressed vs. Tab, and what you plan to do with that information.

If you want to create a custom tab order, this help page describes how to do it. You can even change the tab order “on-the-fly” depending on the data that has been entered.

If you have anything else you want to differently for the tab key vs. the return key, YOU CANNOT DO IT. When the tab key is pressed, it triggers an internal sequence resulting in Panorama skipping to the next field and starting editing of that field. As described in the help page linked above, you can change what Panorama thinks the next field is, but you cannot perform any other action other than tabbing to the next field. You cannot display an alert, open a dialog, open or close a database, switch to a different window, perform a sort or selection, or do ANYTHING ELSE except tabbing to the next field. Attempting to perform some other operation will cause Panorama to misbehave. When you say “it isn’t working”, this is probably what you are seeing.

Panorama X is very customizable, and many of you become so used to being able to customize most things that you think it can/should be able to be modified to perform any way you can dream up. However, this is not always the case. This is one of those situations where you have to accept the way Panorama works - it cannot be changed.

4

This is for my View as List form work around. I have a button that covers the Data Tile that leaves a 1 point border around the selected record, blocking the highlight but not the record text. GetButton does not give the correct position but GetClick does. The button triggers a procedure that opens a single record form directly over the record. The data fields can be edited and tab key moves to the next field while the return key does not. Each field calls a procedure that does several things. I want the procedure to close the form window if the return key was pressed instead of the tab. This way I can open the editing form without the drag bar and have it look almost exactly like a Pan 6 View as List Form.

5

As long as you don’t click on any other window or try to drag the View-as-List window, or use the scroll bar in the View-as-List window. Performing any of those actions will immediately expose the kludge-y nature of this solution.

However, I believe it should be ok to use info(“keyboard”) in this application. Personally I would never design a form like that, but if you like it working that way, it should be ok.