A COM DLL run in the process (EXE) address space and can access only this address space. This is a specification of Windows and not of VFP. All compilers (VB, C++, etc.) must obey to this rule. Windows offer a way the share memory between processes (with API function calls), but I doubt that this option is available to VFP because you need a low-level pointer to memory locations.
A COM EXE run in it's own address space and can be shared by more than one process. This will allow you to share informations between process, but at the cost of marshalling the data between the process and the COM, since the COM and the process do not share the same address space.
There is a Windows object that you can use: it's the message queue (MSMQ). I've never used it with VFP however and I don't know if it does work with it.
For more informations about COM, you can check these articles:
http://fox.wikis.com/wc.dll?Wiki~IntroductionToCOM~VFPhttp://fox.wikis.com/wc.dll?Wiki~IntroToNTierDevelopment~VFPhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html/msdn_dcomarch.aspHTH
>What do they call those types of COMs that allow clients to share the same instance. I think it can be memic`d by seperate instances using a shared table. But it would be better if client 1 could set a COM property - and client 2 could read client 1's affect to that property. Is this out out the realm of being available through some future VFP. Is ther a windows object that we can use to di this?
