>>If you're using function keys quite often (as I do) you may consider adding a method to your base form class: FKeys()
>>
>>Include the following In your startup code:
>>
>>ON KEY LABEL F4 =TrapFKeys()
>>ON KEY LABEL F6 =TrapFKeys()
>>ON KEY LABEL F7 =TrapFKeys()
>>ON KEY LABEL ALT+S =TrapFKeys()
>>.
>>.
>>.
>>
>>
>>PROCEDURE TrapFKeys
>>IF TYPE('_screen.ActiveForm') = 'O'
>> _screen.ActiveForm.Fkeys(LASTKEY())
>>ENDIF
>>
>>In each Form you have the ability to structure CASE statements specific to the active form (you can place default behavior for a common function key in the base class and benefit from inheritance). Placing the procedure FKEYS in your startup code makes it accessible by the entire application.
>>
>>* Form.FKeys()
>>LPARAMETERS nKeyCode
>>DO CASE
>>
>>
>>ENDCASE
>>
>>nKeyPress = LASTKEY()
>>
>>DO CASE
>Daniel,
>
>If you are using function keys in your forms you might want to consider using the keypress method of the form class to ahndle them. OKL's are preoblematic in that they are intercommand interrupts, that is they will interrupt running code. I don't think you really want the user starting a new add while the code for saving the previous record is running.
>
>Since you are suggesting using a form class to do this I would recommedn NOT using OKL's at all but rather setting the fomr classes KeyPreview property to .T. and then trappng the function keys in the form classes KeyPress event. This would be the way to do this in VFP, in FP 2.x there was no keypress evetn and so OKL's were often used where they were not the best solution to the problem (there is also a better way to do this in 2.x but that is a different story).


Jim:

I understand your concerns, however, my form class is fully integrated with my menus and toolbars and contains other custom methods like Add, Delete, Save, Undo... before any record is added, a CheckStatus routine is run that determines if there is a dirty buffer. If so, the user is prompted to Save/Undo before any additional records are added. The OKLs that I use work well with my current framework and, you're right, may not work for everyone. I adopted this system, however, to avoid having trapping ALL keystrokes with the Form,KeyPress(). The peformance hit and appearance (notably in edit boxes) had an impact on my decision.