Zweiter versuch RIO vs Tokyo TStringDynArray

[QuickAndDirty]

Also ich den Post vorher abgeschickt hatte, war ich grundlos wieder ausgeloggt und nach dem einloggen kam der Post nicht durch. Alles geschriebene war verloren.... deswegen jetzt nur kurz...um noch so ein Disaster zu vermeiden.

- Muss die niedrigen Android Versionen mit Tokyo-Kompilaten und die hohen Android Versionen mit RIO-Kompilaten versorgen!
- Benutzte nur einen Webservice für beide Kompilate der selben APP.
- System.Types.TStringDynArray wird oft im Webservice Interfaceteil exportiert
- TMylist = Array of TMyRemotable wird oft im Webservice Interfaceteil exportiert
- TMylist = Array of TMyRemotable wird normal im im WebserviceClient abgebildet.

-In Rio gibt es System.Types.TStringDynArray nicht.
-Codegenerierung erzeugt einen Webservice Client mit TArray<String> anstatt mit TStringDynArray oder array of String
-Wenn ich in RIO Strg+linkclick im Serverinterface auf TStringDynArray klicke dann führt mich das zu

Delphi-Quellcode:

unit System.Types
[...]
type
  TArray<T> = array of T;

-Wenn ich in TOKYO Strg+linkclick in der APP auf TStringDynArray klicke dann führt mich das zu

Delphi-Quellcode:

unit System.Types
[...]
type
  TStringDynArray  = array of String;

Der durch RIO generierte Webservice Client ist natürlich inkompatibel mit Tokyo
Da in der ganzen App TStringDynarray verwendet wird und Tokyo TStringDynArray nicht kompatibel zu TArray<String> interpretiert :(

Warum diese Änderung?
Wo ist der Ausweg?

Embarcadero warum diese Fake DynArrays?
Sad.
How to make DynArrays great again?

Wieso versteht RIO überhaupt was TStringDynArray ist? Ist das kompiler magic? Weil der Bezeichner kommt ja nirgends mehr in der System.types.pas vor.

[Rollo62]

Also bei mit ist

Delphi-Quellcode:

...
  TSingleDynArray       = TArray<Single>;
  {$EXTERNALSYM TSingleDynArray 'System::TSingleDynArray'}
  TDoubleDynArray       = TArray<Double>;
  {$EXTERNALSYM TDoubleDynArray 'System::TDoubleDynArray'}
  TBooleanDynArray      = TArray<Boolean>;
  {$EXTERNALSYM TBooleanDynArray 'System::TBooleanDynArray'}
  TStringDynArray       = TArray<string>;
  {$EXTERNALSYM TStringDynArray 'System::TStringDynArray'}

in den System.Types unter Rio 10.3.1 Enterprise drin.

Edit:
Ok, ich sehe gerade Professional / Enterprise, evtl. ist da der Unterschied.

[QuickAndDirty]

Wow,
also kann es sein das
Delphi Tokyo Professional Typen hat die man in
Delphi Rio Professional nicht bekommt?

Quasi um einen in das Enterprise Abo zu "motivieren"?

Aber selbst dann

Delphi-Quellcode:

TStringDynArray = TArray<string>;

Delphi-Quellcode:

TStringDynArray = array of String;

Wäre doch immernoch nicht kompatibel.

[Whookie]

Also mein RIO Pro kennt das auch...

Delphi-Quellcode:

  TSingleDynArray       = TArray<Single>;
  {$EXTERNALSYM TSingleDynArray 'System::TSingleDynArray'}
  TDoubleDynArray       = TArray<Double>;
  {$EXTERNALSYM TDoubleDynArray 'System::TDoubleDynArray'}
  TBooleanDynArray      = TArray<Boolean>;
  {$EXTERNALSYM TBooleanDynArray 'System::TBooleanDynArray'}
  TStringDynArray       = TArray<string>;
  {$EXTERNALSYM TStringDynArray 'System::TStringDynArray'}

[GPRSNerd]

Kann ich sogar von der Rio Community Edition bestätigen (System.Types.pas):

TStringDynArray = TArray<string>;

Da ist wohl irgendwas anderes das Problem...

[Stevie]

Seit der Einführung von

Delphi-Quellcode:

TArray<T>

hab es immer wieder das Problem, dass ein

Delphi-Quellcode:

TArray<string>

nicht kompatibel war zu

Delphi-Quellcode:

TStringDynArray

, welches historisch in der RTL verwendet wurde, wenn array von string übergeben oder zurückgegeben wurde.

Daher hat man sich schon lange gewünscht (siehe RSP-16737), dass das angeglichen wird - nun endlich die Änderung in 10.3.

Die Deklaration

Delphi-Quellcode:

TStringDynArray = TArray<string>

ist nur ein Typalias im Gegensatz zu der vorherigen Deklaration, wo es ein neuer eigener Typ war (und nein,

Delphi-Quellcode:

TStringDynArray = type TArray<string>

geht nicht).

Welche Implikationen dies nun auf die Kompatibilität von Anwendungen vor und nach 10.3 hat, wurde scheinbar übersehen (war mir auch nicht klar - ich mach nix mit dem eingebauten Webservice Zeugs).

Mir ist nur gerade nicht klar, an welcher Stelle die beiden Versionen nicht kompatibel sind - in der Beschreibung der Webservice Schnittstelle nach außen? Das könnte sich durchaus fixen lassen, indem 10.3 dann erkennt, was es mit einem TStringDynArray oder wie auch immer es nach außen spezifiziert ist, anstellen soll).

Kannst du evtl ein Demoproject erstellen, um den Fehler darzustellen? Lässt sich dann auch gut als Bug bei Embarcadero reporten.

[QuickAndDirty]

Zitat:

Zitat von Stevie (Beitrag 1429212)

Kannst du evtl ein Demoproject erstellen, um den Fehler darzustellen? Lässt sich dann auch gut als Bug bei Embarcadero reporten.

Ich kann meist kein Bug reports in QC machen, weil das alles über meinen Chef gehen müsste.

Zitat:

Zitat von Stevie (Beitrag 1429212)

Mir ist nur gerade nicht klar, an welcher Stelle die beiden Versionen nicht kompatibel sind - in der Beschreibung der Webservice Schnittstelle nach außen? Das könnte sich durchaus fixen lassen, indem 10.3 dann erkennt, was es mit einem TStringDynArray oder wie auch immer es nach außen spezifiziert ist, anstellen soll).

Ich kann es mit einem Muster code verdeutlichen, so das dass problem auch ohne ein Projekt in der IDE zu öffnen deutlich wird.

Ausschnitt Interface unit des Webservice also Also Serverseitig

WebserviceIntf.pas

Delphi-Quellcode:

[...]
type

  TAnswer= Class(TRemotable)
  private
    fsuccess: boolean;
    fError: String;
  published
    property Error:String read fError write FError;       // Fehlermeldung, in der regel eine Exception
    property Success:boolean read fsuccess write fsuccess;// nur false wenn Error angezeigt werden muss
  End;

  TResponseDevicePersonRelation = Class(TAnswer)
  private
    FDevices:  TStringDynArray;
    FResource: TIntegerDynArray;
    FGroups:   TBooleanDynArray;
  public

  published
    property Devices:  TStringDynArray read fDevices write fDevices;    //Handy
    property Resource: TIntegerDynArray read fResource write fResource; //RessourcenID
    property Groups:   TBooleanDynArray read fGroups write fGroups;     //Ist Ressource eine Gruppe
  End;
[...]

Diese Klasse TResponseDevicePersonRelation wird als SOAP envelope bei einer SOAP abfrage durch den Client erzeugt....
Der Webservice erzeugt eine WSDL datei aus der sich eine dieser Delphicode wieder kompatibel erzeugen lässt!
SO SOLLTE ES SEIN!
Es galt immer für Delphi um Listen unter SOAP ordentlich abszubilden zu können müsste man DYNARRAY typen nehmen oder selber Tstrings oder TList<Tobject> serialisieren und deserialisieren.
Natürlich macht man nicht SOAP um selbst den Transport und das serialisieren programmieren zu müssen.
Also DYNARRAY

WebserviceClient.pas generiert aus WSDL datei vor Umstellung auf RIO

Delphi-Quellcode:

  TResponseDevicePersonRelation = class(TAnswer)
  private
    FDevices: TStringDynArray;
    FResource: TIntegerDynArray;
    FGroups: TBooleanDynArray;
  published
    property Devices:  TStringDynArray   read FDevices write FDevices;
    property Resource: TIntegerDynArray  read FResource write FResource;
    property Groups:   TBooleanDynArray  read FGroups write FGroups;
  end;

WebserviceClient.pas generiert aus WSDL datei nach Umstellung auf RIO

Delphi-Quellcode:

  TResponseDevicePersonRelation = class(TAnswer)
    FDevices: TArray<System.string>;
    FResource: TArray<System.Integer>;
    FGroups: TArray<System.Boolean>;
  published
    property Devices:  TArray<System.string>   read FDevices write FDevices;
    property Resource: TArray<System.Integer>  read FResource write FResource;
    property Groups:   TArray<System.Boolean>  read FGroups write FGroups;
  end;

Verwendung der klasse in der APP: Dieser Code ist nicht mehr in Tokyo compilierbar

Delphi-Quellcode:

Procedure Demo;
  function IndexOfDevice(Devices:TStringDynArray):integer
  Begin
    //bla
  end; 
  var aResponseDevicePersonRelation:TResponseDevicePersonRelation 
Begin 
  aResponseDevicePersonRelation := WebserviceClient.Request_DevicePersonRelation(a,b,c);
  myindex := IndexOfDevice(aResponseDevicePersonRelation.Devices);//<------DAS HIER KANN IN RIO KOMPILIERT WERDEN ABER IN TOKYO NICHT
end;

"DAS HIER KANN IN RIO KOMPILIERT WERDEN ABER IN TOKYO NICHT"
weil TStringDynArray in RIO ist

Code:

TStringDynArray = TARRAY<String>;

aber in Berlin ist es

Code:

TStringDynArray = array of String;

Und das mag der compiler nicht.

[TiGü]

Wird denn der "Webservice Interfaceteil", also die Pascal-Unit, die aus der WSDL entstanden ist, denn auch immer mit (neu) kompiliert? In beiden IDE-Versionen / Projekten?

[QuickAndDirty]

Zitat:

Zitat von TiGü (Beitrag 1429215)

Wird denn der "Webservice Interfaceteil", also die Pascal-Unit, die aus der WSDL entstanden ist, denn auch immer mit (neu) kompiliert? In beiden IDE-Versionen / Projekten?

Der Webservice interfaceteil wird nur in RIO kompiliert . Also der auf seiten des Servers!
Der Client Webservice Interfaceteil wird sowohl in RIO als auch in TOKYO kompiliert, weil ich die APP ja builden muss!
Die Code Generierung für den Client machen ich mit RIO weil der Server ja auch mit einem RIO Kompilat läuft.

[TiGü]

Aha, du hast erneut die WSDL importiert und der Importvorgang ersetzt den TStringDynArray-Alias mit dem dahinter liegenden Typen (TArray<string>) beim Import.
Unschön, aber nachvollziehbar. Ggf. kann man das mit einen der unzähligen Einstellmöglichkeiten des WSDL-Imports steuern.

Aber warum importierst du neu?
Es würde doch ausreichen WebserviceClient.pas nur einmalig zu importieren (in Berlin oder Tokyo) und diese Unit auch in dem Projekt zu verwenden, das mit Rio gebuildet wird. So dass die Aliase erhalten bleiben.
Dann sollte dein Problem auch verschwinden.