Tbytedybarray return von einer Funktion

[aals]

Ich habe einen Webservices.
Es gibt eine Funktion gefile.
function getFile(const user: string; const pass: string; const appId: Int64; const retId: Int64; const personId: string; const fileId: string
): TByteDynArray; stdcall;
Bei dieser Funktion parst Delphi das Resultset mit dem XML - Parser. Das ist aber nur ein Binary File.
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><env:Header xmlns:env="http://www.w3.org/2003/05/soap-envelope"/><soap:Body><ns2:getFileResponse xmlns:ns2="http://services.aals.dev/"><return><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:[e-mail]"/></return></ns2:getFileResponse></soap:Body></soap:Envelope>
--uuid:61810b24-98c5-4479-a012-e33b8ec6c069
Content-Type: application/binary
Content-Transfer-Encoding: binary
Content-ID: <[e-mail]>
Das Problem wird nirgend beschrieben. Ich glaube das das ein Delphi-Fehler ist.
die execption ist:
raise EXMLDocError.CreateFmt(Msg, Args);
Ich brauche dringend ein Workaround.

Wer kann mir da helfen? In keinem Forum ist das Problem Beschrieben.

[TiGü]

Was steht denn in

Delphi-Quellcode:

Msg

drin? :?:

Wenn du deine Anfrage ordentlich formatierst, wollen sich bestimmt mehr Leute mit deinen Anliegen auseinandersetzen.
So ist das nur ein einziger wüster Textblock.

Besser wäre gewesen:


Ich habe einen Webservices.
Es gibt eine Funktion getfile.

Delphi-Quellcode:

function getFile(const user: string; const pass: string; const appId: Int64; const retId: Int64; const personId: string; const fileId: string
): TByteDynArray; stdcall;

Bei dieser Funktion parst Delphi das Resultset mit dem XML - Parser.
Das ist aber nur ein Binary File.

Code:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><env:Header xmlns:env="http://www.w3.org/2003/05/soap-envelope"/><soap:Body><ns2:getFileResponse xmlns:ns2="http://services.aals.dev/"><return><xop:Include xmlnsop="http://www.w3.org/2004/08/xop/include" href="cid:[e-mail]"/></return></ns2:getFileResponse></soap:Body></soap:Envelope>
--uuid:61810b24-98c5-4479-a012-e33b8ec6c069
Content-Type: application/binary
Content-Transfer-Encoding: binary
Content-ID: <[e-mail]>

Das Problem wird nirgend beschrieben. Ich glaube das das ein Delphi-Fehler ist.
die execption ist:

Delphi-Quellcode:

raise EXMLDocError.CreateFmt(Msg, Args);

Ich brauche dringend ein Workaround.

[aals]

Danke für die FORMATIERUNG:
ich hoffe dass sich jemand meldet.

[TiGü]

Zitat:

Zitat von TiGü (Beitrag 1264677)

Was steht denn in

Delphi-Quellcode:

Msg

drin? :?:

Siehe oben!

[Der schöne Günther]

wat? Mit

Delphi-Quellcode:

Msg

meint er den konkreten Text der Exception.

PS: Es lässt sich noch schöner formatieren :love:

Code:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
   <env:Header xmlns:env="http://www.w3.org/2003/05/soap-envelope"/>
   <soap:Body>
      <ns2:getFileResponse xmlns:ns2="http://services.aals.dev/">
         <return>
            <xop:Include 
               xmlnsop="http://www.w3.org/2004/08/xop/include" 
               href="cid:[e-mail]"
            />
         </return>
      </ns2:getFileResponse>
   </soap:Body>
</soap:Envelope>

[TiGü]

Zitat:

Zitat von Der schöne Günther (Beitrag 1264716)

wat? Mit

Delphi-Quellcode:

Msg

meint er den konkreten Text der Exception.

Ja eben!

Guck mal in die Xml.XMLDoc-Unit.
Da gibt es 15 Stellen, wo die Funktion XMLDocError aufgerufen wird (XE3), die dann eine EXMLDocError auslöst.

Da er hier anscheinend in die Variante mit CreateFmt reinläuft, gibt es drei mögliche Quellen (Zeilen 898, 1137 und 1949).

Der konkrete Text der Exception würde ihn und auch uns helfen ihn zu helfen!

[Sir Rufo]

Zitat:

Zitat von TiGü (Beitrag 1264734)

Der konkrete Text der Exception würde ihn und auch uns helfen ihn zu helfen!

Die Bitte den Quelltext zu formatieren und den konkreten Text der Exception noch nachzureichen hatte ich schon per PN an den TE geschickt.

Reaktion (wie man sieht) gleich Null :roll:

[aals]

Vielen Dank.
Die exception ist "Element return enthält keinen keinen einzelnen Textknoten"
KEIN WUNDER ES IST JA EIN BINARY Feld. "Tbytedynarray"
Delphi definiert es selber im WSDL - File drin.
An dieser Stelle kann ein (PDF,jpeg,png,,,,) Typ zurück kommen SOAP UI kann das prima.

[TiGü]

Mir ist die Herkunft von GetFile noch unklar.
Ist das eine Funktion von dir?
Wenn ja, wo ist der Quelltext zur Funktion?

[aals]

Das ist ein Webservice.
auf unserem Server. Wohl verstanden mit dem Program SOAPUI (das ist gratis) läuft es

Ich habe den WebServer mal auf mein Amazon gestellt. Hier der link:
http://soaptest-env.elasticbeanstalk...rvicePort?wsdl

Jetzt kannst Du ein Online Soap Client ausprobieren wie dieser:
http://www.soapclient.com/soaptest.html

[TiGü]

Kenn mich mit Webservice und SOAP null aus.

Kannst du nicht ein ganz kleines lauffähiges Projekt hochladen (ja, kein Quelltext-Schnipsel), anhand dessen man dem Problem hinterherdebuggen kann?

[aals]

Zuerst einmal vielen Dank.

Ich habe jetzt Wochen verbraucht um mit Delphi, Java und Soap vernüpftig anzusprechen, aber das ist erfolglos. Es ist aussichtslos. Irgend einen Wetterdienst das kann glaube ich jedes gratis Tool.
Man sollte nicht auf die Presalles hören, da geht immer alles fine.
Delphi kann kein Soap mit Namespace ansprechen, da brauche man riesen Erfahrung, dass die richtigen Parameter zu setzen. Standardmässig kann er es nicht. Ich will auch nicht IDE Entwickler werden.
Ich bedanke mich für die Hilfe, aber es ist eine Schande wenn Emarcadero Leute sich hinter allen Posten verstecken und sich freuen, wie Leute Ihre Fehler suchen.

of wederluege, wir in der Schweiz kennen Produkthaftung. Vielleicht werde ich mich auf die berufen. Ich möchte eigentlich nicht bezahlen für etwas was ich nicht ändern kann.

[Sherlock]

Na dann, viel Erfolg. Berichte bitte, wie es ausging.

Sherlock

[aals]

Ich habe mich entschlossen die Delphilizenzen auf ebay zu verkaufen. Von einer Cross-Plattform IDE erwarte ich mehr als nur ein Ediitfeld und einen Button auf eine Maske zu kleben.
Da sich Google in seinem BS nicht für Pascal entschieden hat ist das zwangsläufig.
Soap hört nicht bei einer einfachen Wetterabfrage auf.
Ohne eine gescheite Javabridge kann man sich auch nicht an grössere Projekte wagen.
Genug Frust, vielleicht gibt es ja eine Lösung.

[mkinzler]

Zitat:

Da sich Google in seinem BS nicht für Pascal entschieden hat ist das zwangsläufig.

Kein aktuelles Betriebssystem setzt auf Pascal genausowenig wie auf Basic, LUA, Python usw. Deshalb dürften nach Deinem Verständnis immer nur die jeweils die Sprache für die sich der Entwickler des jeweiligen Systems entscheiden hat in Frage kommen.
Apple setzt auf Objective C und neuerdings Swift, ich vermute mal dass trotzdem ein großer Teil der Software für OSX/iOS in C/C++ entwickelt wurde.

Zitat:

Soap hört nicht bei einer einfachen Wetterabfrage auf.

Nein und mit Delphi ist auch mehr möglich als eine Wetterabfrage.

Zitat:

Ohne eine gescheite Javabridge kann man sich auch nicht an grössere Projekte wagen.

Besonderst sind große Windowsprojekte ohne eine solche total undenkbar :mrgreen:
Man kann es für gut oder schlecht halten, dass EMBT auf das NDK und JNI setzt, ist aber wohl der einfachste Weg eine plattformübergreifende Lösung wie diese zu bieten ( mit all den Schwächen die diese hat). Es wäre weit komplexer Delphicode direkt in Java Bytecode zu kompilieren (aber möglich wie RO gezeigt hat). Aber die JavaBridge (JNI) funktioniert eigentlich recht gut.

[aals]

Guten Abend,

Bis jetzt sind eigentliche nur Lobeshymnen auf Delphi gesungen worden und Keine Lösungen.
Ich habe jetzt Visual Studio und xamarin genommen und siehe ich bin Weiter gekommen.

Ich kann die Delphi Lizenzen zu 70% abgeben, vielleicht hat eine Interesse.

[aals]

Noch die allerletzten Information.

Ich habe jetzt VS genommen; Das ganze läuft auf Anhieb. Wenn man Support braucht gibt es genügend Leute die einem helfen, gegen einen Obolus.

Scheinbar soll das ganze unter Delphi laufen sagen die einen Delphi-Leute, die verraten es aber nicht.
Die andere behauten Delphi unterstützt MTom nicht.

Egal, ich habe eine tolle Lösung, und ist mit Xamarin auch Plattformübergreifend.
Es ist sehr elegant.