Hi, Tracy.

>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?

Well, maybe the misunderstanding was thinking that this toolkit would make .NET classes easier to understand to a VFP developer. The fact is that -as described- it would allow you to call some classes, but then you have to know how to use them anyway, with the con of lacking the aid of the VS.NET IDE, Intellisense, etc. This way it seems harder to use than from VS.NET right away.

I think that like you, some other people understood that this would make .NET classes appear like VFP native classes or commands, but this is not what was propossed.

Regards,