Interesting....

My response is two fold.

First, why couldn't I just use the msxml com component?

Second, assuming that the system.xml namespace is a better way to go, why would'nt I just create a .NET class to do what I want - and then expose that class via com/interop? In the long run, wouldn't I be better off writing a .NET component that was a consumer and producer of XML - and then just have Fox be the client to that component?





I see from your example, objects are getting exposed in VFP - which may be of some value. Still, this is a task that we have been able to do for a long time with msxml.

Tehcnical benefits - in the air - without practical application - don't mean much.

I am not missing any technical benefit for the one notable reason that you have not put forth a single benefit. I don't see XML being a good vehicle for this because we have been able to use XML in Fox for a long time.

Why not spend time on features that would have more use to a broader segment of VFP developers?

Seems to me there is no real intrinsic technical benefit. The only goal I see is in getting Fox developers to use use .NET - in some fashion - and this is a vehicle to reach that goal.

FWIW, I do think it is a good idea that Fox developers get into using .NET. This to me seems like a half-baked - half-assed way of doing it however. It is like RV's and cursor-adapters and working with server-based RDBMS's. It is a non-value added intermediate step that buffers people from the actual workings - thus impeding their ability to learn what is actually going on.

I don't buy it...but I am sure my opinion and whether I buy into it is of little value to the analysis.


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