Asynchronous processing??

[mike777]

Hello folks.
OK, so I don't really know if that's what it's called that I want to do, but I thought "asynchronous processing" would sound impressive and maybe attract the best minds to my question!! Most likely, though, I probably just sound like somebody that doesn't understand the words he's using. Alas...my friends, in time.
If you're still with me and my best attempt at a little (little) humor, here's what I'm trying to do:
I have been doing a lot of automation lately with Excel, and today, with Internet Explorer.
There are situations (like when I do a print preview in Excel, or use automation to click certain buttons on a web page) where when I use the automation it locks up FoxPro. With Excel, for example, if you create a worksheet, then issue the PrintPreview command from FoxPro, FoxPro locks up (I'm using the term "locks up" like it's a malfunction; it's not, really) until the person switches over to Excel and prints out the worksheet and closes the Print Preview window.
I just encountered the same thing with IE when I clicked on a button that opened a Get File Dialog box.
I was wondering if there was some way to issue one of these commands, and then "disconnect" FoxPro from the ... client, I think, or would it be server...application, so that the other app can be there in limbo, but my operator can continue to use FoxPro at will and get to the other thing "whenever".
Is this possible?
I searched the FAQ's and saw something there about forcing a second application to the forefront of the machine, which is good, and which I hope to be able to learn to use, but it is not exactly what I am trying to do at the moment.
Any help you can provide will be greatly appreciated.
With grandiloquent and ostentatious verbosity, I bid you farewell for now.
-Mike

 

[baltman]

Look for multi-threading. It is possible, but you need to create dlls or com servers to pass off the process you want done and have it report back to your app when their finished.

Brian

 

[baltman]

I found some info at

http://fox.wikis.com/wc.dll?Wiki~MultiThreadedVFP~VFP

Brian

 

[KeithTrangmar]

Just an idea, you could write your automation code in something like VBscript & then use ShellExecute to run the script, which would then be ticking along in it's own thread. You'd have to figure out some mechanism for the script to notify your application if/when it finishes, assuming you need to know that.

Certainly not as elegant as the concept of using multi-threading in VFP, but probably simpler to implement.




Keith Trangmar
Harlend Computer Services
Maidstone, Kent. UK.

 

[rgbean]

Tamar Granor had a very interesting approach to this "problem" in an article in FoxPro Advisor Magazine - the December 2003 issue. "Take Advantage of Idle Cycles - Use this technique to make your application work even when the user isn't."

http://foxpro.advisor.com/doc/13180

Unfortunately you've got to be a subsciber to read it, but if you need some ideas, it might be worth it.

Rick

 

[mike777]

Hello all.
Trying to absorb all this.
Many thanks.
-Mike

 

[baltman]

Keith,

You can always shellexecute a compiled program (open .fxp) and have it write a textfile "ImDone.txt" when it completes... or you can createobject a new instance of VFP and automate it with a "ImDone.txt" upon completion... so the 'main' VFP would keep doing it's thing until it needs the spun off process results upon which it looks for "ImDone.txt" and waits...

The shellexecute would quit itself, and the createobject would be controlable.

Brian