>>Is this entirely correct? What about a proxy/wrapper class in .NET? I understand that sealed classes cannot be inherited. I don't recall seeing the sealed property on any of these classes. IAC, it seems to me that a wrapper/proxy sceanrio could achieve substantively the same thing.
>
>
In order to create a COM wrapper class for a .NET Framework base class, you must first subclass and then expose as a COM object. Things like the XMLReader in System.Xml do not allow subclassing, so the only way to do this in .NET would be to create a new class and map all the PEMs via delegation which is not would anyone would want to have to do. Maybe you can try it out and see if you see how this works, or find anything interesting on the topic.
>

You have made my point Ken. Here is what you wrote:


Most important is System.Xml, since those classes cannot be subclasses in .NET and therefore you cannot create COM wrappers for them to call within VFP using VS .NET.


What you are saying is that BECUASE the .NET classes are sealed, you cannot subclass them and therefore, cannot create com/interop interfaces.

The flaw of course is that subclassing is the only vehicle available to you re: com/interop. Of course - as we know - and as you say above - this is not true. What is required is a .NET class. The class could indeed subclass a .NET class. OR, it could simply act as a proxy. When I wrote the stuff in Code Magazine some time ago, I believe I did just that.

I'm sure I will get accused yet again of nit-picking on words here - but so be it.

Ken, your position presupposes a more fundemental point -and that is this: what is there in the msxml com component that would make the system.xml .net namespace a more compelling alternative? And, assuming there were techncially compelling reasons to justify this work, what % of Fox developers would really take advantage of the benefit?

My understanding of the issue is that there is no technical justification and even if there was technical justification, a very small % of Fox Developers would take advantage.

So then....it gets back to my original point of "why bother????"

I say that Ken in light of the fact there are numerous requests that are:

1. Much more technically compelling and;
2. Would be of use to a greater % of Fox developers

For example, full support in com debugging, full event support, lifting the 2gb limit on dbfs, lifting the 10 character limit on index tags, better integration with sql server, etc. I am sure there are more. And yet all the while, it is stuff like this, an alleged "utility" that would provide easier access to .NET classes from Fox.

Why not concentrate on features that have technical justification and broader appeal to your customer base?