Schlagwort-Archive: Bug

Delphi 10.1 Berlin :: Android SDK installation path changed

This is one of those little inconsistency that occur with every new release of RAD-Studio / Delphi and drive me crazy. (Like the removal of the favorites with no better replacement, still makes me upset !).

Instead of being installed in $(BDSPLATFORMSDKSDIR) it is now in $(BDSCatalogRepository).

QC Embarcadero RSP-14826

Delphi 10.1 Berlin :: Form Inheritance and Layout.Padding Bug

Simple FMX app having base form with a Layout.padding set to (20,20,20,20) and a few inherited forms.
Few of them have different settings for padding, but changed, saved and reopened: 

Changes are not saved, I checked the *.fmx file !

So do I really have to set each Layout’s padding individual by hand ? Per platform ? Oh boy this is crazy !!!

(Embarcadero QC RSP-14294)

Delphi 10.1 Berlin THTTPClient Trouble

Ein KO Kriterium für den Einsatz von Delphi 10.1 war eine Exception vom Typ EZCompressionError in einem FMX Projekt, welches mit Delphi 10.0 einwandfrei funktioniert.

Bei der Ursachensuche musste ich feststellen, dass die Interna von THTTPClient – und allem was damit zusammenhängt – sich grundlegend geändert haben:
In IHTTPResponse.ContentAsString wird jetzt z.B. das „Content-Encoding“ abgefragt und falls dieses „gzip“ ist, wird ein Compression Stream für die Ausgabe erzeugt, in 10.0. wurde das „Content-Encoding“ ignoriert. Und da kracht es gleich beim Login.
Mit HTTPClient.AcceptEncoding := ‚identity‘ war das Problem erstmal vom Tisch (womit jedes serverseitige Encoding  unterbunden wird).

Das nächste Probleme:
Egal welches Encoding, Charset etc, beim Abruf der JSON Daten vom Server, wenn intern die Streams umkopiert werden, kommt immer die Exception EEncodingError „Keine Zuordnung für Unicode-Zeichen in der Multibyte-Zielcodeseite vorhanden“. (Es ist egal, was für das Encoding angegeben ist: serverseitig ANSI)

Nach langem Hin und Her und einigen Stunden Debugging:
Wenn entweder ein Stream im HTTPClient.Post() für den Response übergeben oder Response.ContentStream abgefragt wird (in TStringStream umkopieren), dann klappt das ohne Exception und es gibt lesbaren Response String.
Aber: Der Response enthält keine JSON Daten sondern HTML! Was geht nun schief ?
Fiddler zeigt alles als korrekt an, das Sever Log zeigt keine (offensichtlichen) Fehler.

Negativ ist in diesem Zusammenhang die Hilfe aufgefallen: Ich bin da auf zu viele Einträge mit “ … zu diesem Zeitpunkt keine weiteren Informationen“ gestossen.

Fortsetzung folgt (wahrscheinlich, nicht garantiert)