>That should have read g_extprg call, not g_exprg
>
>>Erin,
>>
>>That will work fine. You just have to call your form using the g_exprg call rather than just entering "DO FORM whatever" in the hotkey setup screen.
>>
>>Just check the SBT docs for the format for g_exprg calls.
>>
>>Bill
>>
>>
>>>I have actually created a form within fox that is accessible through a hotkey. the user presses alt-7 in sbt, and the executable that contains my form fires. then, there are 3 option buttons on the form. the 3 option buttons represent 3 different forms in report writer that the user has the option to view. an option is selected, and then a command button is clicked. when the command button is clicked, the line of code that i pasted on the previous message fires. can i do it this way?? please don't tell me no!! :)

You can fire the line of code as shown by sticking it in a memvar and macro-expanding it easily enough; it's your job to preserve the system context so that when your stuff completes, you can return to the state before the code fired. To me, this would imply that you use a private datasession for your app, that you retain the current context (active form, datasession, etc) and that your code is modal - nothing else runs while your code is active. It's your responsibility to ensure that any variables you need are visible and in scope, and that you protect them - do passes variables by reference, so changes to a variable will pass back. If you use an OKL, realize that 'thisform' is meaningless - you need to query the _screen.ActiveForm to find the form reference if you need things contained in the current form, before you fire up your own forms, and save the object ref so that it's available from your code unambiguously (depending on form names to provide public variables as object refs is wishful thinking at best.)