Ken,

I hate to say this but this is a really bad example...

If you go down the path of using the .Net components for a job it would be a heck of a lot more performant to use managed code to do this stuff than to step back and forth between even an intermediate Managed C++ dll (which I assume this is?)...

The point being if you're already dealing with the XmlReader (the main benefit of which is speed - which would be lost in this excercise) which means you have to know the syntax and intricacies anyway. Using Fox you loose the performance, the accesibility (intellisense), the debugging and you end up with code mixed in two places and just look at the code you presented (!) with the need to call property gets and overloads with numeric postfixes etc... Plus you're adding the overhead of the CLR to your Fox code... For low level access like this a .Net interop scenario is a bad call.

There are legit reasons to use interop, but I think if you're going to interact with data in this way, using a .Net wrapper is going to provide much greater benefit both to the application as well as the developer. For one it will likely provide reusability (I've done this in a number of places with Help Builder and it works very well if you have clean objects to expose) whereas if you access native components like this you're more than likely to hack it directly into your front end.

To suggest accessing this sort of thing out of Fox code is a bad design suggestion to be made IMHO... If people are using Interop in the first place I think it'll be less out of necessity than the desire to play with the 'other' technology and start using it as part of a solution. The first step for that is to actually write code in that environment and creating wrappers is one of the easiest ways to get your feet wet actually by allowing small chunks of code to be created.



+++ Rick ---



>This toolkit is not part of VFP, it has nothing to do with the VFP product development or features. It is a toolkit that is an add-on written in C++ and VFP to allow some .NET Framework classes to be used directly from within VFP. I think you are missing the possible technical benefits of using it from within VFP, like in the System.Xml case. Rather than subclassing a .NET class and then creating a COM object wrapper requiring VS, you can simply run code like this directly in VFP and never have to open or use VS or anything .NET related other than having the .NET Framework installed (which is free)...
>
>
>CLEAR
>* Load .NET wrappers
>PUBLIC NET as NETWrapper of HOME(7) + "NETClasses\NETBase.prg")
>NET = newOBJECT("NETWrapper", HOME(7) + "NETClasses\NETBase.prg")
>NET.Using("System")
>NET.Using("System.Xml")
>NET.Using("System.Xml.Schema")
>
>*Make an XML file, so we can load it
>SET SAFETY off
>USE HOME(2) + "Northwind\Customers"
>CURSORTOXML(ALIAS(), "myXMLFile.xml", 1, 512, 5, "1")
>
>LOCAL XMLDoc as NETSystemXml_XmlDocument OF HOME(7) + "NETClasses\NETSystemXml.prg"
>XMLDoc = NET.New("NETSystemXml_XmlDocument")
>
>XMLDoc.load3("myXMLFile.xml")
>
>ShowMe(XMLDoc.get_ChildNodes(), 0)
>
>*Recursively displays each ChildNode
>PROCEDURE ShowMe(XMLNodeList as Variant, depth as Integer)
> LOCAL i as Integer
> LOCAL XMLNode as NETSystemXml_XmlNode
> XMLNode = NET.Declare("NETSystemXml_XmlNode")
>
> FOR EACH item IN XMLNodeList
> XMLNode.setobject(item)
>
> strVal = XMLNode.get_value()
> strVal = IIF (ISNULL(strVal), "", strVal)
>
> ? REPLICATE(" ", depth)
> ?? XMLNode.get_name() + " : " + strVal
>
> ShowMe(XMLNode.get_ChildNodes(), depth + 1)
> ENDFOR
>ENDPROC
>