Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Still processing even Getfile
Message
De
21/05/1999 09:08:35
 
 
À
21/05/1999 08:53:09
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00221277
Message ID:
00221332
Vues:
16
>>>>Hi,
>>>> I have a long process, when user click a button to select file using GETFILE(), the running long proces stop. How to make the long process kepp running even select file from open dialog box??
>>>>
>>>>Thank you
>>>
>>>I don't believe you can within a single VFP application. That would require multi-threading and VFP is not multi-threaded ( except the apartment type for COM ).
>>>
>>
>>I agree with you on this. the only way I can think of to do this would be to actually have multiple VFP executables running independent of each other (if synchronization was needed, some sort of semaphoring could be used to signal the completion of a spawned task; you could use API_APPRUN to launch another VFP session using the LaunchApp method, and then poll for its termination using the CheckProcessExitCode method. This has the advantage of letting two things go on independently, but obviously, there'd be multiple copies of the VFP environbment up and running, and competing for CPU cycles and memory.
>>
>
>Hi Ed,
>
>I had thought about the possibility of spawning new "occurences" of a VFP app to accomplish this type of task. But off the top of my head the logistics seemed like it would probably such a nightmare to sync them ( assuming they needed to be synced some how ), it wouldn't be worth the gain. :-)
>

It actually isn't terribly painful with API_APPRUN; you need to limit VFP's voracious appetite for memory using SYS(3050), and without using a semaphoring mechanism (I'd tend to use the API and memory-mapped file I/O, but it's very non-trivial to implement), it's only easy to let a 'master' program know when the 'child' completes its work. If API_APPRUN is available you could do:
SET CLASSLIB TO PROCESS ADDITIVE
oProc = CREATEOBJ('API_APPRUN','MyOtherVFPApp.EXE',,'MIN')  && runs minimized
oProc.LaunchApp() && fires up the second or later VFP session
*
*  Do something
*
*  Whenever you need to know if the child finished:
IF oProc.CheckProcessExitCode() # 259  && 259 means still going
   *  It finished - you can proceed knowing the other job finished
   oProc = ''  && releases the process object
ELSE
   *  It's still running, so you should poll again later
ENDIF
Destroying oProc won't force the other job to terminate, but there is a KillProc method that forces the child process to shut down (messily.)

You can have multiple processes running in parallel this way; termination of the parent won't stop a running child process, so you can spawn long, time consuming reports and things and still shut down the main application while the child is running, without aborting the child process. You can pass command line parameters to the child as with any VFP executable, and you can run the second app from a different directory without affecting the current default directory or path for the parent application.

I use exactly this technique in some of my own applications, and it works as long as you have plenty of memory available.
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform