LongMonthNames

[mse]

http://svn.freepascal.org/svn/fpc/branches/cpstrnew mag ich dafür jetzt nicht installieren. fpc trunk hab ich, seit manche meiner bug reports bearbeitet wurden. Zum Beseitigen der Fehler brauchte ich fpc trunk.

cpstrnew ist seit einiger Zeit in FPC trunk gemerged, das ist ja das Problem.

Martin

[marcov]

http://svn.freepascal.org/svn/fpc/branches/cpstrnew mag ich dafür jetzt nicht installieren. fpc trunk hab ich, seit manche meiner bug reports bearbeitet wurden. Zum Beseitigen der Fehler brauchte ich fpc trunk.

cpstrnew ist seit einiger Zeit in FPC trunk gemerged, das ist ja das Problem.

Fuer Theo funktionierts mit 2.7.1?

[theo]

Fuer Theo funktionierts mit 2.7.1?

Ja, allerdings unter Linux crosscompiled x86_64-win64 und unter Wine ausgeführt.

[Heinrich Wolf]

ich finde es schade, dass die Umlaute in FormatSettings.LongMonthNames[] im IBM Code belegt sind und nicht in UTF8. Bei Delphi 5 auf meinem deutschen Windows sind sie im CP1252 Code belegt.

Sie sind nicht nur in Delphi 5, sondern auch in Lazarus im CP1252 Code belegt. Ich glaubte, in Lazarus sei es ÍBM Code, weil sie da in einer Console ohne explizite Umwandlung korrekt angezeit werden. Findet hier eine implizite Umwandlung statt? In Delphi 5 muss ich die Umlaute für eine Console Anwendung umwandeln.

Wenn ich in einer internationalen Lazarus Anwendung einen LongMonthName auf der Windows Oberfläche anzeigen möchte, muss ich GuessEncoding aufrufen und an ConvertEncoding übergeben. Ist das zuverlässig, oder kommt dabei evtl. eine falsche Codierung raus? Wie kann ich stattdessen die Codierung, die im Betriebssystem eingestellt ist, abfragen, um sie an ConvertEncoding zu übergeben?

Ich traue dem GuessEncoding nicht. Außerdem finde ich es zuviel Overhead. Inzwischen hab ich in der LConvEncoding Unit GetDefaultTextEncoding gefunden und werde das zusammen mit ConvertEncoding verwenden.

[theo]

SysToUTF8 müsste eigentlich reichen.
Was bei dir falsch ist, kann ich nicht sagen.
Auf allen meinen Tests hat das gut funktioniert. (Win2k 32, Win7 64, Wine 64).

Lade mal ein super-einfaches Demo Projekt hoch, das bei dir den Fehler zeigt.
Vielleicht reden wir ja aneinander vorbei?

[Heinrich Wolf]

Lade mal ein super-einfaches Demo Projekt hoch, das bei dir den Fehler zeigt.
Vielleicht reden wir ja aneinander vorbei?

Demo ist anbei

Heiner

[theo]

Ja, sehr merkwürdig.

Deine EXE auf Linux-Wine ausgeführt, zeigt den Fehler, den du beschreibst.
Wenn ich aber deinen Code selber kompiliere, mit Lazarus 1.1 r36929M FPC 2.7.1 x86_64-linux-gtk 2 und Win64 Crosscompiler, dann ist
alles gut.

Siehe Anhang: Oben meine EXE unten deine EXE.

Kann sich das jemand erklären?
Hast du vllt. einen ungünstigen FPC Snapshot erwischt?

[Heinrich Wolf]

Hast du vllt. einen ungünstigen FPC Snapshot erwischt?

Ich versuch mal ein svn up.

Inzwischen hab ich svn up erledigt und bin am Compilieren des fpc. Da hagelt es tausende Warnungen über implizite String Konvertierungen mit möglichem Datenverlust. maerz.zip hab ich erstellt mit den svn Versionen fpc 20264 und Lazarus 35222. svn up hat mir die Versionen fpc 21013 und Lazarus 37006 gebracht. Mal sehen, was dabei heraus kommt.

maerz.zip ist erstellt mit Lazarus 0.9.31 . Durch svn up bin ich bei Lazarus 1.1 gelandet.

Mit dem neuen fpc und Lazarus funktioniert SysToUTF8 wieder. Auch AnsiToUTF8 funktioniert wieder.

[Heinrich Wolf]

Vielen Dank an Theo für das Nachvollziehen und den Tip in Richtung svn up.