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...