Hi Martin,

I don't argue whether it is the best way to do it or not. Following this thread though it appeared that what started out as a means for VFP developers to utilize some of the strengths of .net internally from within VFP without learning .net first has now turned out to be the best way to do this is to create it in .net and then expose it to VFP which requires .net language capabilities. That completely takes away the ability for any VFP developers not knowledgeable in .net and once again pushes those developers into .net. While I believe that learning .net is ideal for all vfp developers (IMHO), it is disheartening to find out that that will be the only way now in the future for VFP developers to utilize any of the capabilities of .net rather than those options initially discussed in this thread. It started out as a promising possibility in VFP and has returned to if you want to do that, you must use .net.

Have I misunderstood anything?

Tracy


>>Very good summary of the situation Martin. You can do all of what you need today by working with .NET classes using a .NET langauge and then exposing that custom object as a COM object and using it within VFP. The only difference in this and a generic COM object is in the details of how the interaction is done, and the pros and cons between them - not in the ability to do something versus the non-ability to do something.
>
>Well, I think that we'll see over time more and more community-built tools based on COM wrappers around .NET classes. The good thing with this is that provided a good interface is designed and documented, a VFP developer would be able to leverage some .NET strenghts without actually have to worry about learning the stuff behind. Not what I would recommend in most cases, but useful if you just need some missing feature in VFP.
>
>I guess several of this components would be far more useful than a do-it-all approach that doesn't isolate each platform from its particularities.
>
>See you,