Some things are correct, others not, and some incomplete.

- A VFP COM DLL (in process) cannot have ANY UI. That includes Messagebox, Wait Window, forms, and even the "Printing report" dialog.

- The COM DLL must be registered. On the development machine, it happens automatically when you build. For distribution, include the .tlb file (generated when you compile), the DLL, the proper runtime (for MTDLL or STDLL), and the DLL. Then tell ISX to register it.

See me article at http://www.craigberntson.com/Articles/kb019.pdf. While it's about COM+, which I don't think is what you want for this, it does review basic COM stuff.

>This is an exchange I had with someone recently and wanted to know if someone could verify that the assertions sound reasonable. Any additional insight/references welcome as well. There are a couple gaps where there was proprietary information, but the gist of it is here. Thanks!
>
>
>

>
>ME: What do you know about creating/using COM servers in VFP?
>
>THEM: you just create object
>THEM: then use it like any other foxpro object
>
>ME: have a VFP9 service that I wrote that now needs to be used if possible, or at
>least the class it utilizes, in the EM app, called from code/form (@...SAY) to send
>data to a port. I would like to use the same class that only works in VFP9 - someone
>said it could be done using a COM server.
>
>THEM: if you create an instance of the com object in fms at the start of the main
>routine then it will be available as a global object in any routine and you should be
>able to call its methods
>
>THEM: you can build a com object as an exe or as a dll
>
>ME: which is preferred and why?
>
>THEM: the dll is called an in process com object.  when started it runs within the
>memory and treading of the calling exe.  the good part is it is fast the bad part is
>if it blows up it takes the exe with it.
>
>THEM: an exe is called an out of process com object it runs in its own memory and and
>own thread. which means interprocess comunication wich is slow. but if it blows up it
>does not nessicarily take down the exe
>
>ME: Pretty much what I though - I might try to go with the dll then. How are those
>registered, etc?
>
>THEM: i dont think you need to register it as long as it is in the same dir as the exe
>but im not sure about that
>
>ME: I think you may be right - that sounds familiar. So, a dll is just like an exe as
>far as how I develop it in VFP? Just how I compile it that is different? Can I take a
>visual class, drop it on a non-visible form and just reference it in my code?
>
>ME: Or do I even need the form?
>
>ME: The problem is that the class that i'm using was not written by me - it has properties
>methods unavailable for editing - I would like to reuse this class in the next part of my
>development. The class is visual, not code based
>