Du kannst es - zumindest für Tokyo - wie folgt lösen.
Der entscheidende Punkt ist das Freigeben der betreffenden Klasse in der überschriebenen ConvertSoapToNativeData-Methode.
Delphi-Quellcode:
procedure ConvertSoapToNativeData(DataP: Pointer; TypeInfo: PTypeInfo;
RootNode, Node: IXMLNode; Translate: Boolean); override;
// ^^^^^^^^
D.h. in Tokyo sind diese Funktionen von
TOPToSoapDomConvert jetzt virtuell und überladbar?
Sowohl in Berlin als auch für Tokyo ist die public-Methode
ConvertSoapToNativeData
als
dynmamic
gekennzeichnet und daher überschreibbar.
Der Fix würde also für beide Versionen funktionieren.
Ich werde Deinen Vorschlag für einen Workaround ausprobieren (vielen Dank für den Beispielcode!!).
Gern geschehen!
Es ist schon traurig, dass man überhaupt einen Workaround implementieren muss, für eine Toolchain + Framework in dieser Preisklasse
.
Beschäftige dich dann mal lieber nicht mit dem internen REST-Framework.
Ich musste in Delphi Berlin darüber eine Datei schicken, was ums verrecken nicht funktionieren wollte.
Ein hinterherdebuggen zeigte, dass die gesamte Funktionalität dafür noch nicht da war bzw. auskommentiert.
Erst der Umstieg auf Tokyo und wieder eine Überschreibung einer wichtigen Methode brachte die Lösung.
Leider hat Emba die Unart, viele wichtige Klassendefinitionen nur im implementation-Teil zu schieben, was einige Fixes sehr erschwert.