>Yes! We saw demos of using VFP6 COM objects in VB and intellisense worked beutifully. Apparently, the type library creation problems have been fixed.
>
>>Also, does VFP6 compile type library information for VFP6 COM objects in a manner more consistent with other MS tools like VB

Let me clarify something I posted earlier concerning type libraries and Intellisense. I just noticed that in VFP5, it compiles COM object methods properly in the type library (with parameters and types of values expected, etc.) for native VFP5 methods. It does not specify the type of value expected for native VFP5 properties, though, which is odd, since if it is available in method parameters it should also be available for properties. For methods created by the developer, parameters and value types expected are not listed. For properties created by the developer, value types expected are not listed.

Also, Intellisense only works for objects that are explicitly declared in VB5. (For example, DIM oDataObject as VFP5ComObject.Class1, where VFP5ComObject.Class1 is the VFP5 COM object) However, if you use this code along with SET oDataObject = NEW VFP5ComObject.Class1 to instantiate the object, the class won't load properly and the program will bomb. In order to actually create and run the object, you have to modify the variable declaration to a generic object reference, and then use SET oDataObject = CREATEOBJECT("VFP5ComObject.Class1"). I suspect the problem is that VFP5 does not support the creation of COM objects that can be early bound. This results in a two-step process of having to code for early-binding to be able to use Intellisense with VFP5 objects (which still suffer from the limitations of the first paragraph), and then change the code for late-binding and CREATEOBJECT in order to actually run the code.

This has to be fixed in VFP6 in order for developers that don't use VFP as their primary tool to consider it for data-intensive COM objects. Unfortunately, because Visual Basic is the tool of choice for many, these features in future versions of VFP will have to conform to the de facto standards set by that tool. That goes not only for COM object type libraries but for ActiveX control support as well. This type of support in VFP will help open it up to the larger development community. What do you think? I'd like your opinion.