>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:
FOR i = 1 to 3
oCOM1 = createobject('MyCom.COMClass')
oCOM1.RunTask('A')
oCOM2 = createobject('MyCom.COMClass')
oCOM2.RunTask('B')
oCOM3 = createobject('MyCom.COMClass')
oCOM3.RunTask('C')
NEXT
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