Zweiter versuch RIO vs Tokyo TStringDynArray

[QuickAndDirty]

Zitat von Stevie:

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 von Stevie:

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.