>I'm breaking apart the routines that makes up the FPD Event Handler, just to see what it's going to take.
>
>Your pointers are GREAT..... Help is Good... Pointers are GREAT....
>The inkey() which is all there is in FPD calls a read when the enter key is pressed. That triggers the Validation Routines.

In a grid, you catch that moment in grid's .BRCC (beforeRowColChange) event. You get the column's .columnorder as a parameter, which is usually the same as the column's index (unless you changed columnorders) but can be used to find the index.

>My description of a "Dialog Box" was a poor description, in FPD terms I'm just "Painting the Screen". The screen is usually divided into three "Windows" which appear as one. Header (Basic Information and Totals), Body (where the scroll routines [grid] takes place, footer usually line 24 for key instructions.

You can use tooltips, small labels etc... and pretty much use buttons instead of capturing keystrokes. And even if you capture keystrokes, assign them to buttons and have them in button captions - "F3 - dance" would be a good caption for the button which calls thisform.dance() from its click event. Also, there's a trick: if you don't want the click of such a button to shift the focus to the button (i.e. you want the focus to stay on the grid), then don't use the .click event, but rather the .when of the button:

thisform.MyMethod()
return .f.

Many here will advise you that you shouldn't put code in an object's event, other than a single line to call a method in your form (or maybe of a bizobject on your form), and I will agree with them. Not that I've always listened to this advice each time - but then got forms where it was very hard to locate the code which does something. A form method called .FireUpTheBarbecue() is quite clear, while .pageframe1.page3.container1.commandbutton3.click is the best place to have your code lost in.