>>>>To create an object from a class definition: Look in the Help at
>>>CreateObject() and AddObject().
>>>>
>>>>SET CLASSLIB only tells VFP where to look for class definitions. It
>>>doesn't create any object.
>>
>>In my form class I emulate the behavior of what I've had in FPD, which
>>reacted on F3 and F4. In the form class init, I have
>>

>>on key label f3 _screen.activeform.f3f4(3)
>>on key label f4 _screen.activeform.f3f4(4)
>>

>
>This works only if you have a form on screen and if that form has an F3F4 method.
>
>In my opinion this shouldn't be in the form's Init, but in the main program/app class Init.
>
>I would do it like that:
>
>PROCEDURE F3F4
>PARAMETER lnKeyIndex
>IF TYPE("_SCREEN.ActiveForm.Name") = "C" and ;
> PEMSTATUS("_SCREEN.ActiveForm", "f3f4", 5)
> _SCREEN.ActiveForm.f3f4(lnKeyIndex)
>ENDIF
>RETURN
>
>And change your ON KEY to:
>
>ON KEY LABEL F3 DO F3F4(3)
>ON KEY LABEL F4 DO F3F4(4)
>
>Of course, the F3F4 proc may be a method in your app class.
>
>>Maybe I should move it to form's Activate, and also dismiss in any
>>proper place (it gets dismissed in Unload now)... which event fires if
>>the form's window is not the active window anymore?
>
>If you do it as I stated above, you don't need to worry about the dismiss of those settings anymore.

Just wanted to quote a response from Ted Roche, Contributing Editor at FoxPro Advisor about the danger of ON KEY LABEL (OKL):

"The problem is that OKLs are part of the event loop that FoxPro checks between each line of processing code. If you inadvertently press an OKL key while generating a menu, building a project, or running your application, the OKL fires immediatly. An OKL that isn't careful about restoring the environment in witch it's running (such as changing work areas, SET settings, etc.) could have disastrous effects on running code. For that reason, other alternatives, if available, are usually preferable."