Umlaute & ß in SysErrorMessage

[Delphi-Laie]

Hallo Freepascalfreunde!

Daß Lazarus bzw. Freepascal - wenigstens in der Standardeinstellung - mit den Sonderzeichen (Umlaute und ß) auf Kriegsfuß stehen, daran habe ich mich mittlerweile gewöhnt. Mit einem nachgestellten e hinter den Vokalen und einem Doppel-s hatte ich mir bisher so schlecht und recht darob hinweggeholfen.

Doch bei der Funktion SysErrorMessage (z.B. SysErrorMessage(1): "Unzulässige Funktion") (diese Funktion also unter Windows genutzt), kann man sich nicht mehr darob hinwegmogeln, die optische Ausgabe legt das offen.

Nun glaubte ich an einen Fehler und versuchte es mit einem Fehlerbericht im Bugtrucker, doch trotz aller Mühe, die rührende Hilfe und Kümmerung nachzuvollziehen, und weiterer Recherche bin ich immer noch genau dort, wo ich war, also so schlau (als) wie zuvor.

Wie bekommt man nun die Sonderzeichen auch ausgegeben, also z.B. bei

Code: Alles auswählen

showmessage(syserrormessage(1))

?

Vielen Dank im voraus für Aufmerksamkeit und Bemühen sowie freundlicher Gruß

Delphi-Laie

[marcov]

Wie schon gesagt, FPC nutzt der System Codierung. Lazarus immer utf8.

Ich weiß nicht genau welcher Funktion Lazarus nutzt um Programmunabhängig System nach UTF-8 Codierung um zu setzen. (weil der System Codierung auch UTF-8 kann sein auf Linux)

[Delphi-Laie]

Hallo Marco, vielen Dank, Du hast viel Geduld mit mir, vielleicht bin ich auch ein mittelschwieriger Fall.

Also, FPC und Lazarus nutzen unterschiedliche Codierungen. Welche Codierung überhaupt infrage kommt, wenn man mit Lazarus ein Formularprogramm schreibt und dieses vom Unterbau FPC dann compiliert wird, ist nicht klar.

Mir würde ja schon helfen, wenn ich wüßte, wo (IDE? Quelltext?) ich welche Befehle oder Eingaben probieren könnte, um vielleicht doch noch den Text so auf den Bildschirm gezaubert zu bekommen, wie es schon Turbo-/Borland-Pascal und Delphi seit Version 1 (!) konnten/können. Zugegeben, das eine ist ein reines DOS-, das andere ein reines Windowsprogramm, die sich der Plattformüberübergreifbarkeit nicht stellen mußten.

Die vielen Fragen in diesem Forum und die Antworten, aus denen zumindest nicht so leicht schlauzuwerden ist, lassen in mir den Verdacht aufkommen, daß dieses sprachspezifische Problem derzeit noch nicht (vollends) gelöst ist und daß noch daran gearbeitet wird.

[Socke]

Also, FPC und Lazarus nutzen unterschiedliche Codierungen. Welche Codierung überhaupt infrage kommt, wenn man mit Lazarus ein Formularprogramm schreibt und dieses vom Unterbau FPC dann compiliert wird, ist nicht klar.

Für grafische LCL-Anwendungen solltest du deine Quelltexte in UTF-8 speichern und alle Zeichenketten als ganz normale Ansistrings deklarieren.
Immer wenn du mit der RTL arbeitest, kannst du entweder einige Wrapper-Funktionen aus der LCL-Unit FileUtil (für Dateizugriff) verwenden oder du wandelst alles manuell aus der Unit LCLProc mit UTF8ToSys() bzw. SysToUTF8() um.

Da die RTL unter Windows aber noch alte ANSI-API-Funktionen verwendet, kannst du zur Zeit nur mit direkten API-Aufrufen die volle Unicodeunterstützung von Windows herausholen. Ansonsten bleibst du immer auf einen Single-Byte-Zeichensatz beschränkt (welcher das ist hängt soweit ich weiß von den Benutzereinstellungen ab).

[Delphi-Laie]

Hallo Socke, vielen Dank!

Auch Deine Hilfe ist eher kryptisch, aber sie läßt sich ansatzweise verwenden. Der Reihe nach:

Also, FPC und Lazarus nutzen unterschiedliche Codierungen. Welche Codierung überhaupt infrage kommt, wenn man mit Lazarus ein Formularprogramm schreibt und dieses vom Unterbau FPC dann compiliert wird, ist nicht klar.

Für grafische LCL-Anwendungen solltest du deine Quelltexte in UTF-8 speichern

Davon lese ich immer und immer wieder gerade in diesem Forum. Doch was zum Teufel hat die Codierung des Quelltextes (!) mit einer fehlenden Funktion eines Compilates (die ihm eben durch die Compilierung nicht mitgegeben wurden) zu tun?

und alle Zeichenketten als ganz normale Ansistrings deklarieren.

Ich versuchte schon alles mögliche: AnsiString, WideString....

Immer wenn du mit der RTL arbeitest, kannst du entweder einige Wrapper-Funktionen aus der LCL-Unit FileUtil (für Dateizugriff) verwenden

Was sind "Wrapper-Funktionen", und wieso kann ich "einige" verwenden? Ich suche nur eine Funktion, und zwar die, die obiges ermöglichst. Verstehe ich nicht.

oder du wandelst alles manuell aus der Unit LCLProc mit UTF8ToSys() bzw. SysToUTF8() um.

Manuell? Immerhin finde ich dieser Deiner Zeile erstmalig einen Unitnamen und - anscheinend - Funktionsnamen, die die gesuchte Funktionalität bieten könnten.

Da die RTL unter Windows aber noch alte ANSI-API-Funktionen verwendet, kannst du zur Zeit nur mit direkten API-Aufrufen die volle Unicodeunterstützung von Windows herausholen. Ansonsten bleibst du immer auf einen Single-Byte-Zeichensatz beschränkt (welcher das ist hängt soweit ich weiß von den Benutzereinstellungen ab).

API? Die Funktion "SysErrorMessage" bedient sich doch auch nur der API-Funktion "FormatMessageA". Den Quelltext von SysErrorMessage von FPC und von Delphi ausprobiert, modifiziert, wieder ausprobiert.

Vielversprechend scheint auch das hier zu sein.

Alles in allem: Ich danke Dir für Deine Mühe, aber Hilfe in engeren Sinne, also was einem wirklich weiterbringt, muß ich auch aus Deinem Fleiß mühsam extrahieren, wie überhaupt alles, was ich bisher in diesem Forum fand. Ich komme mir wie ein Archäologe vor.


Update: Des Rätsels (erste und noch nicht sonderlich schöne, vielleicht noch verbesserbare) Lösung ist

Code: Alles auswählen

UTF16ToUTF8(SysErrorMessage(1));

War es sooo kompliziert, mir das mitzuteilen?

Dank und Grüße

Delphi-Laie

Edit 1: Dein oben angegebenes

Code: Alles auswählen

SysToUTF8(SysErrorMessage(1));

sowie außerdem

Code: Alles auswählen

AnsiToUTF8(SysErrorMessage(1));

funktionieren genauso wie meine erste Lösung.

[Socke]

Ich war in meinem Post auf die allgemeine Frage eingegangen, wie mit Unicode (im Speziellen UTF-8) in Lazarus und Free Pascal gearbeitet werden kann. Daher wohl die Verwirrung. Die Funktion SysErrorMessage() habe ich zu meiner Schande nicht einmal angeschaut, aber das hole ich jetzt nach.

Was sind "Wrapper-Funktionen", und wieso kann ich "einige" verwenden? Ich suche nur eine Funktion, und zwar die, die obiges ermöglichst. Verstehe ich nicht.

Eine Wrapper-Funktion (engl. to wrap = verpacken, umhüllen) dient nur dazu eine andere Funktion auf bequemere Art und Weise aufzurufen, indem z.B. Parameter mit Standardwerten belegt werden oder nur für diese Funktion benötigte Programmlogik implementiert wird.
In diesem Sinne ist auch SysErrorMessage() eine Wrapper-Funktion um FormatMessageA().

Nun zu deinem Problem:
FormatMessageA() liefert (so schließe ich allein aus dem Funktionsnamen und der Deklaration) einen Zeiger auf einen String, der in einem Single-Byte-Zeichensatz kodiert ist (Parametertyp ist LPSTR). Die richtige Lösung um einen UTF-8 kodierten String zu erhalten wäre also

Code: Alles auswählen

SysToUTF8(SysErrorMessage(1));

Das ganze hat sich auch irgendwer anders gedacht und genau das in FileUtil.SysErrorMessageUTF8() implementiert.

[Delphi-Laie]

Ach so. Derlei "Wrapperfunktionen" hat Delphi und sicher auch Freepascal zuhauf zu bieten, garantiert auch andere Programmiersprachen. Die API-Aufrufe in Windows sind auch fast alle ekelhaft - ständig diese Zeiger; vielleicht sieht es in anderen Betriebsprogrammen ähnlich umständlich aus.

In Einzelfällen sind diese "Wrapper" jedoch nachteilig, nämlich, wenn sie fehlerhaft sind oder den Informationsgehalt des Funktionswertes verringern. Beides habe ich schon erlebt: z.B. SetThreadIdealProcessor gibt als API integer, in Delphi jedoch nur Longbool zurück; OpenProcessToken wurde in Delphi 2 falsch deklariert; oder, wenn ich schon dabei bin, auch eine leere Prozedur wie die TRegistryIniFile.UpdateFile in der unit registry des Delphis 4.

Da ich nun weiß, wie man die Sonderzeichen darstellt (es funktioniert auch an anderen Stellen meines Lazarus-/FPC-Programmes), kann diese Diskussion meinetwegen ruhen.

Dir nochmals besten Dank, auch wenn es schon mehr als eine Zangengeburt war und schon stark in Richtung Kaiserschnitt tendierte!

Gruß

Delphi-Laie

[Delphi-Laie]

Ergänzung: In der zentralen Lazarus-Projektdatei „.lpr“ helfen die o.a. Funktionen trotz Aufnahme von „lclproc“ im uses-Abschnitt bei der Zuweisung für Application.Title nicht: UTF16TOUTF8 und AnsiToUTF8 verhindern das Erzeugen „merkwürdiger“ Zeichen nicht, und SysToUTF8 wird gar nicht erst gefunden.

[shokwave]

Kann es sein, dass du eine ziemlich alte Version von FPC/Lazarus benutzt?
Ich hab gerade mal auf 'nem XP SP3 mit FPC 2.5.1 und Lazarus 0.9.31 probiert und

Code: Alles auswählen

Application.Title:='Täßt';

funktioniert ohne zusätzliche Funktionen. Vielleicht wartest du einfach noch ein bisschen auf die 0.9.30 oder probierst mal einen Snapshot aus.

Wie weiter oben schon mal erwähnt, ist es wichtig, dass der Quellcode das richtige Encoding hat. Um das zu prüfen/korrigieren kannst du mal "Werkzeuge/Kodierung von Projekten/Packages konvertieren..." aufrufen. In der Liste unten werden die Dateien deines Projektes aufgelistet, die nicht als UTF8 gespeichert sind.

[Delphi-Laie]

Kann es sein, dass du eine ziemlich alte Version von FPC/Lazarus benutzt?

Hängt davon ab, was man unter „alt“ versteht. Also, beim 32-Bit-Lazarus benutze ich das letzte „offizielle Release“, also 0.28.2 mit FPC 2.2.4. Bei 64 Bit hatte das letzte „offizielle Release“ einen entscheidenden Fehler (Keine Mausunterstützung beim Positionieren und Zoomen der graphischen Komponenten), die nächste Version dann auch (Anzahl der Prozessoren bzw. Prozessorkerne wurde falsch ermittelt und/oder an das aufrufende Programm zurückgegeben), so daß ich mich davon trennte und seitdem mit verschiedenen neueren Versionen experimentiere.

Daß es bei Application.Title nicht funktioniert, bezog sich auf die 32-Bit-Variante. Da ich das mit dem letzten „offizielle Release“ feststellte, sehe ich nicht, mich auf eine veraltete Version mit dieser Aussage bezogen zu haben. Bei 64 Bit werde ich es noch ausprobieren.

Aber danke, daß ich jetzt weiß, daß auch das mit einer neueren Version behoben sein könnte. Doch ohne Not werde ich mich von einem „offizielle Release“ nicht verabschieden, und das aus gutem, auch Dir sicher bekannten Grunde: „Snapshots“ beherbergen keine Funktionsgarantie. Allerding muß ich zur Ehrenrettung sagen, daß das Abenteuerrisiko beim De- und Installieren nach meiner Beobachtung deutlich abgenommen hat. Lazarus wird eben - zum Glück - immer besser.