ich denke du willst einfach aus:
[...]
nur die reinen "Daten" haben:
Korrekt. Das sagt ja aber nichts darüber aus, wie diese Daten vorliegen, woher sie kommen; eine Datei ist anders zu behandeln als ein String. Und ich schrieb ja im OP schon
Zitat:
Es gibt noch andere
XML-Dokumente, die analog zu diesem aufgebaut sind - Rückgabe einer Fritzbox eben
* Der Funktion GetEnvelope(Doc: IXMLDocument) kann ein
XML Document übergeben werden dass nicht als Datei "auf der Platte" vorliegen muss.
Oh, das hab ich in der Tat übersehen
. Mal sehen, was ich daraus basteln kann.
Zitat:
* Namespaces werden unterstützt
OK, ich führe es wohl doch noch etwas weiter aus, wo ich Probleme hatte, und warum ich diese Frage stellte. Ich begann mit
LXMLDoc.ChildNodes['s:Envelope'].ChildNodes['s:Body'].ChildNodes['u:GetCommonLinkPropertiesResponse']
, bekam aber immer eine
Exception mit dem Inhalt "Node ... not found". Der Node war nachvollziehbar vorhanden, zumal der Zugriff via
ChildNodes[0]
einwandfrei funktionierte. Also grenzte ich etwas ein, und fand heraus, dass das letzte ChildNodes der Auslöser der
Exception war. Irgendwann schwante mir, dass die verschiedenen Namespaces der Knoten damit zu tun haben müssten. Deswegen die Änderung auf
FindNode
mit leerem Namespace wie im OP zu sehen.
Da ich in dem vom Wizard generierten Code außer der Konstanten
TargetNamespace
keinerlei Namespaces sehe, frage ich mich, wie das funktionieren soll, wenn Body und der Datenknoten darunter jeweils andere Namespaces verwenden. Geht das automatisch oder muss ich das explizit angeben, und wenn ja wie?
Zitat:
* das "Mehr an Code" wird ja nur einmal, automatisch, generiert. Ab dann spart es sehr viel Zeit für das Schreiben des Codes, um auf die gewünschten Elemente zuzugreifen
Stimmt, aber durch die bereits im OP genannte Auslagerung in eine Methode hab ich auch kaum mehr Schreibarbeit - ohne dieses Mehr an Code. OK, wahrscheinlich ist es nicht so "typsicher" wie der Code des Wizard.
Grüße
Dalai