Zweiter versuch RIO vs Tokyo TStringDynArray

[QuickAndDirty]

Ich importiere die ja auch nur einmal für beide compilate!
Leider will Tokyo den Import nicht von RIO nicht! Und er passt ja auch offensichtlich nicht!
Es sei denn ich stelle in diesem seit XE8 gewachsenen sehr umfangreichen projekt alle verwendung von DYNARRAYs und WEBSERVICE aufrufe um.

Das Problem ist nicht eine code stelle wo ich ein DYNARRAY übergebe sondern das ich das eben extensiv nutze..


Ich habe zuletzt neu importiert, weil in RIO TXSDatetime einen bug hat und den Client crashed wenn man TXSDatetime.AsDatetime := 0.0 schreibt.
Habe also neue Funktionen eingebuat die Datetime als iso8061 transportieren....

Außerdem entwickle ich den Webservice und die App immer weiter und muss immer wieder neu importieren...

So importiere.
Import Script für batch file

Code:

c:
cd c:\myproject\MYSCLIENT
powershell.exe -Command "(new-object System.Net.WebClient).DownloadFile('http://myapp.mycompany.com:1234/wsdl/IMyWebService','IMyWebServiceClient.xml') "
Pause
c:
CD C:\Program Files (x86)\Embarcadero\Studio\20.0\bin
WSDLIMP -P -Ov+ -Oz- -DC:\myproject\MYSCLIENT C:\myproject\MYSCLIENT\IMyWebServiceClient.xml
Pause

Ich brauche aber vermutlich eine lösung für den EXPORT...

Diese inkompatible Umstellung der Typen ist für mich echt nicht schön....
Vielleicht hilft es eine eigene System.types zu verwenden... vorrausgesetz Embarcadero hat seine eigenen bibliotheken nicht auch umgestellt und ist jetzt auf diesen geänderten Typ angewiesen...

[TiGü]

Zitat:

Leider will Tokyo den Import nicht von RIO nicht! Und er passt ja auch offensichtlich nicht!

Dreh das mal um, dann wird alles gut!
In Tokyo importieren, die Aliase bleiben erhalten und kann in Rio-Projekt verwendet werden.

[TiGü]

Hat jetzt nur sekundär mit deinen Problem zu tun, aber vielleicht hilft es den einen oder anderen interessierten Leser bei ähnlichen Problemen:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

type
  TMyLittleStringArray1 = array of string;
  TMyLittleStringArray2 = TArray<string>;
  TMyLittleStringArray3 = TArray<string>;
  TMyLittleStringArray4 = TMyLittleStringArray1;
  TMyLittleStringArray5 = type TMyLittleStringArray1;
  TMyLittleStringArray6 = array of string;

var
  One: TMyLittleStringArray1;
  Two: TMyLittleStringArray2;
  Three: TMyLittleStringArray3;
  Four: TMyLittleStringArray4;
  Five: TMyLittleStringArray5;
  Six: TMyLittleStringArray6;
begin
//  One := Two; // [dcc32 Error] Project1.dpr(19): E2010 Incompatible types: 'TMyLittleStringArray1' and 'System.TArray<System.string>'
//  Two := One; // [dcc32 Error] Project1.dpr(20): E2010 Incompatible types: 'System.TArray<System.string>' and 'TMyLittleStringArray1'
  One := TMyLittleStringArray1(Two); // geht durch casten
  Two := TMyLittleStringArray2(One); // geht durch casten
  Three := Two; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  Two := Three; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  One := Four; // geht, weil nur Alias und sonst gleicher Typ
//  Five := One; // geht nicht, da durch type Schlüsselwort ein neuer Typ gebildet wird
//  One := Six; // geht auch nicht, weil neuer Typ -> ja, auch wenn bei beiden = array of string steht
end.

[QuickAndDirty]

Je nach dem ob das Problem beim erstellen oder beim importieren der WSDL Datei passiert.

Das ganze stimmt mich alles etwas traurig...

[TiGü]

Zitat von QuickAndDirty:

Je nach dem ob das Problem beim erstellen oder beim importieren der WSDL Datei passiert.

Das ganze stimmt mich alles etwas traurig...

Die Pascal-Unit für den Client wird doch DURCH das importieren erst erstellt!?

Du musst einfach für alle Projekte (egal ob Delphi 7, 2009, Berlin, Tokyo, Rio oder Buxtehude am Ende kompiliert und gebaut) diejenige importierte Client-Unit nehmen, die noch die TXXXDynArray-Aliase für die Member und Properties deiner SOAP-Objekte hat.
Dann ist alles gut und es gibt kein Problem.

[QuickAndDirty]

Zitat von TiGü:

Hat jetzt nur sekundär mit deinen Problem zu tun, aber vielleicht hilft es den einen oder anderen interessierten Leser bei ähnlichen Problemen:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

type
  TMyLittleStringArray1 = array of string;
  TMyLittleStringArray2 = TArray<string>;
  TMyLittleStringArray3 = TArray<string>;
  TMyLittleStringArray4 = TMyLittleStringArray1;
  TMyLittleStringArray5 = type TMyLittleStringArray1;
  TMyLittleStringArray6 = array of string;

var
  One: TMyLittleStringArray1;
  Two: TMyLittleStringArray2;
  Three: TMyLittleStringArray3;
  Four: TMyLittleStringArray4;
  Five: TMyLittleStringArray5;
  Six: TMyLittleStringArray6;
begin
//  One := Two; // [dcc32 Error] Project1.dpr(19): E2010 Incompatible types: 'TMyLittleStringArray1' and 'System.TArray<System.string>'
//  Two := One; // [dcc32 Error] Project1.dpr(20): E2010 Incompatible types: 'System.TArray<System.string>' and 'TMyLittleStringArray1'
  One := TMyLittleStringArray1(Two); // geht durch casten
  Two := TMyLittleStringArray2(One); // geht durch casten
  Three := Two; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  Two := Three; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  One := Four; // geht, weil nur Alias und sonst gleicher Typ
//  Five := One; // geht nicht, da durch type Schlüsselwort ein neuer Typ gebildet wird
//  One := Six; // geht auch nicht, weil neuer Typ -> ja, auch wenn bei beiden = array of string steht
end.

Sowas ist wieder ein klassischer Fall von Irrsin der einen Ducktyping vermissen lässt oder?
Gerade beim bilden der SOAP Schnittstelle...

[TiGü]

Zitat von QuickAndDirty:

Sowas ist wieder ein klassischer Fall von Irrsin der einen Ducktyping vermissen lässt oder?
Gerade beim bilden der SOAP Schnittstelle...

Nein, denn damit (also aufgrund von dynamischen Typensystem) hat man dann wieder anderen Irrsinn.

Aber hast du denn jetzt meinen Rat umgesetzt?
Mit der Verwendung der Tokyo-Unit im Rio-Projekt (und nicht umgekehrt) sollten ja alle deine Probleme verschwinden.

[QuickAndDirty]

Ja das Problem ist schon in der WSDL datei.
Da der Webservice ein RIO Kompilat ist gibt er eine WSDL Datei aus die auch TOKYO veranlasst eine TARRAY<String> als Typen in der Client datei zu verwenden.

Der Umstieg von TOKYO -> RIO hat quasi implizit das Komplette Interface zu dem Webservice zu neuen Typen portiert....
kaum zu fassen...

Webservice kompiliert mit Tokyo: WSDL datei

Code:

      <xs:complexType name="TResponseDevicePersonRelation">
        <xs:complexContent>
          <xs:extension base="ns1:TAnswer">
            <sequence xmlns="http://www.w3.org/2001/XMLSchema">
              <xs:element name="Devices" type="ns2:TStringDynArray"/>
              <xs:element name="Resource" type="ns2:TIntegerDynArray"/>
              <xs:element name="Groups" type="ns2:TBooleanDynArray"/>
            </sequence>
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>

Webservice kompiliert mit RIO: WSDL datei

Code:

      <xs:complexType name="TResponseDevicePersonRelation">
        <xs:complexContent>
          <xs:extension base="ns1:TAnswer">
            <sequence xmlns="http://www.w3.org/2001/XMLSchema">
              <xs:element name="Devices" type="ns2:TArray&lt;System.string&gt;"/>
              <xs:element name="Resource" type="ns2:TArray&lt;System.Integer&gt;"/>
              <xs:element name="Groups" type="ns2:TArray&lt;System.Boolean&gt;"/>
            </sequence>
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>

[Schokohase]

[OT]Internet ist Neuland[/OT]

[QuickAndDirty]

Zitat von Schokohase:

[OT]Internet ist Neuland[/OT]

Bitte lösen. Wo ist der Link ?
Meinst du den hier?
https://en.delphipraxis.net/topic/52...ponse-problem/
Der soviel sagt wie : Mach bloß nichts mit RIO und HTTP , das ist komplett recoded und zerstört?