Hi Robert,

>I do beleive you can do almost everything you can do in .NET as you can do in VFP; and visa-versa. The developer needs to develope knowledge, classes, tools in whichever tool he uses. In the case of the Macro Substitution it seems like a lot more work, and may not be as relevant as it use to be. For example, the Macro Sub was generally a way to work around a limitation, .NET may not have these limitations.

I don't think that is the case. Handling late bind COM objects requires reflection as well as handling untyped recordsets. And of course in VFP the marco substitution is used to build commands on the fly for what ever reason. That is not easy to do in .NET. There is no direct equivalent to EXECSCRIPT() for example. You'll have to get this through reflection.

Kevin, is however referring to using interfaces where it is much easier to dress up objects and let the OO design do its work. Some developers, would go for functionality that checks for the existance of methods and properties though reflection (in VFP you would use PEMSTATUS(), TYPE(),etc) where with interfaces you can do without by just asking the object if it has a certain interface. The compile time type checking in .NET is of big influence of where you have to use reflection. In cases where you simply don't know the type at designtime you still have to use reflection.

Walter,