Hi John,
>I have read all the threads on this subject and asynchronous processing. I have searched the web and MS.
You should've just read the FPW docs ;-)

>I have a VFE/VFP/COM app. I use it as a dll.
I am not sure if you can keep it this way if you follow my recommondation, perhaps you'll need to compile into an exe.

>In my 2.6 app, I use the COM object to pull some data. I can not wait for the data to be delivered (approx. 8 seconds). I need to "ask" for the data and move on to do other things.
Just a comment: This can be trouble down the road because you'll get "inflexible" to change requests.

>I suppose I could modify the COM object to do something, that the 2.6 app could check regularly, to see if the COM object has completed it's data delivery task yet.
Just a "semaphore table", which means a record through which the apps talk together.
Should be enough for the time frames specified.

>
>I do not mind reading but I can't start at the advanced level. Can someone tell me what VFP functionality provides what I am looking for?
You need process communication. Use either a table read/write from both apps OR an asynchrone DDE call from FPW app into VFP (read it up in the FPW docs). COM and FPW are a PITA. If you want to use COM, you should think about porting the FPW app - minimal port will do. It's less work than you imagine <g>. Still, a callback, which is the functionality you really seem to miss, is given to vfp only by 3rd party libraries, some of them in the download section. DDE, which was implemented in FPW and is still supported, gives you callback functionality documented in the product without any tools. Since FPW is not supported anymore, this is a not so important fact today - nobody to holler at on the phone<g>.

No easy scenario, but certainly not impossible. We went this way with when only part of a rather large part app was rewritten. Since process communication was the backbone (AND there were some mysterious failings of the DDE-method depending on OS/HW combinations reported) we designed it as DDE mechanism with a safety backdrop though a "semaphore" table.

This way the VFP component can message the FPW part that processing is done. Giving the possibility of a direct callback into a FPW function on completion of the task in the VFP part gives you faster communication, but processing in the FPW app can also proceed if you go for table based messaging. But this was DDE's finest point, giving you the power of mutlitasking OS to work in something similar to threads.

When I took over the FPW app (now in vfp as well, but still not rewritten in the new framework - money reasons <g>) I cleaned up some code and nowadays DDE works on about 6000 machines, but the table based safety net is still there. Works like clockwork, but you have to set up the DDE mechanism/function registration on the VFP side. Rewriting it to more "current" COM / callback mechanisms wouldn't have given any new functionality, and change just for the sake of change wont get any support from me. In the table based scenarios we settled on task checking any 22 ms on very fast machines, slower times depending on the processing power for other machines, and there are other ways in FPW (idle loop event handler written in c/c++ as well). But from what you describe, it shouldn't be necessary.

Not exactly the area you were expecting, but it fits everything I understood from your description.

HTH

thomas