Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
SBT, Foxfire, and FoxPro
Message
De
03/10/2000 18:09:52
 
 
À
03/10/2000 17:46:03
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire de rapports & Rapports
Divers
Thread ID:
00422165
Message ID:
00424446
Vues:
23
Hi Ed,

As you probably might recall from your not so pleasant memories of SBT :-) The call to this program was done through the SBT shell and using the system manager. By adding the call to g_extprg, this effectively saves the environment for the programmer and then sets it back when the call is complete. Erin's only problem was an erroneous message comming from the report that he called through the report manager. It is pretty easily avoided by using the built-in SBT routines.

Bill

>>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.)
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform