Hi John,
1.) to get a vfp mtdll to work in multiple threads, it has to be called from a multi-threaded client like C++ or IIS. So, that rules out calling a vfp mtdll from vfp.
2.) However, this is not a problem. Check out message #910725 concerning using a timer to have a process running in the background while the vfp app stays active , although, Sylvain may have already given it to you...

>I have read all the threads on this subject and asynchronous processing. I have searched the web and MS.
>
>Trouble is everything is so "over my head" that I am unsure I would know the answer if I saw it.
>
>I have 10 years exposure (probably 3 years hard time) coding FoxPro 2.6.
>I have 3 years experience coding VFP 3.0 - VFP 7.0 with 2 years using Visual FoxExpress framework. So, it seems I should be able to understand a little something.
>
>My question:
>
>I have a VFE/VFP/COM app. I use it as a dll.
>
>I use this dll from inside a 2.6 style program that is part of a 2.6 style application (EXE). Everything runs under VFP 7.0 and WinXP Pro.
>
>I use the dll to perform database processing. It basically "views" data and is used to update data in that database. This database is otherwise maintained by a different VFE/VFP app. So basically I have a COM object that is used from my 2.6 app, to access the database maintained by a different app.
>
>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.
>
>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.
>
>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?
>
>This may be useful in understanding my experience level: I can tell you my COM object is not multithreaded or at least I do not think so. I mention this because some of the threads I have read seem to lean toward MTDLL's. I coded the COM app but a lot of it is still a bit tough for me to comprehend.
>
>Thanks,
>John