>>>>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!
>>>
>>>Some of them are not correct. From what I understand you have a chance to compile it some way. If it's so why would you ever want to create a COM and deal with COM problems. Creating a COM and using it as a 'server' looks appealing but it's also a trouble IMHO. Instead create your objects as needed using those libraries. In code the difference looks like:
>>>
>>>*COM
>>>oMyObject = createobject('myCOMDLL.myCOMClass')
>>>
>>>*non COM
>>>oMyObject = newObject('myClass','myClassLib.prg') && or myClasslib.vcx
>>>
>>>I would go with the latter (but that's me).
>>>Cetin
>>
>>So, I don't need a COM, just a new object in my VFP8 code to reference the VFP9 class?
>
>If the class' code is not there you can't recompile and as soon as a VFP9 specific function/command encountered it'd error. Same thing with creating a COM. How would you create a COM without using VFP9 with a VFP9 compiled lib? If you have ability to do that then you can compile all under VFP9. There is no VFP8 in equation.
>
>It's getting harder to explain in plain English, hopefully you see what I'm saying.
>Cetin

I have a huge application written in VFP8 that we are not going to recompile with VFP9. The class I want to use is written specifically VFP9 and above with no ability to use directly in VFP8. I'm unable to edit many of the methods/properties. I want to use this class because it does exactly what I want it to and I have already used it in a very small VFP9 service. I will build the COM in VFP9, then reference it from the VFP8 code. Or that is what I believe I can do.