>>You can do that if you have some process that can fire the VFP COM instances (like a Web Server running ASP or other backend, or a multi-threaded app written in C++, Delphi etc. that supports multiple threads of execution). Multithreading in VFP is not really multi-threading - it's apartment model COM instancing which essentially allows multiple COM instances to run simultaneously. It doesn't mean that VFP can run multiple threads of operation...

If I understand you correctly this will not work if my COM object was written in VFP:

*  CORRECTION; there should be no FOR NEXT
  oCOM1 = createobject('MyCom.COMClass')
  oCOM1.RunTask('A')
  oCOM2 = createobject('MyCom.COMClass')
  oCOM2.RunTask('B')
  oCOM3 = createobject('MyCom.COMClass')
  oCOM3.RunTask('C')
*-- the following lines work!
oXLS1 = createobject('Excel.Application')
oXLS2 = createobject('Excel.Application')

>>So, if your solution is all VFP then you will need x number of instances of your app running simultaneously.

This is my fallback position; I still have two months though, and try my darnest best to understand COM and see how I can make use of it. I've gathered lots of whitepapers on COM from your site and those mentioned by Mike Helland.

>>The article I mentioned is one way to do VFP->VFP client server in asynch manner. It's not always the most efficient way but async operations rarely are even in a real MT environment...

I've read it last night and I find it very helpful. Makes me wonder why you hadn't had this as one of your sessions at the Orlando DevCon as it is a very good topic. I wouldn't have missed it.

>>You can do what you want, but it will take resources to do...
>
And a lot of surfing... wish I could do that too.

ramil
~~ learning to stand still