Inoffizielles deutsches Xbase-Forum

Hallo,

ich habe ein Problem mit dem XbpFileDialog(). Wenn ich dort unter :title einen String mit Umlaut eingebe, wird das falsch dargestellt. Beispiel: Steht da ein "Mandant wählen", erscheint im Dialog als Titel ein "Mandant wShlen". Das gleiche gilt auch für :fileFilters.

Das Programm ist voll GUI, und in der AppSys steht ein SET CHARSET TO ANSI. Auch der gesamte Quellcode ist ANSI. System ist Windows 10 1909 64 Bit.

Ich hab dann mal, Windows ist ja UTF-8, das per Char2Utf8() konvertiert, auch wenn ich erwarten würde das die Xbase-Funktion solche Konvertierungen selber vornimmt. Das Ergebnis ist noch viel wilder: "Mandant w+ñhlen"

Hat da jemand eine Idee zu?

Jan

Hi Jan
Das hängt von deinem Editor ab
- Wenn du ANSI editierst, musst du /ga setzen

Grüße

Ich stimme zu dass es vom Editor abhängt, aber /GA oder /GO sind gefährlich !

/ga Converts literal strings from ANSI to OEM

When the /ga switch is set, all literal character strings in the PRG source code are converted from ANSI to OEM before the compiler creates the OBJ file.

/go Converts literal strings from OEM to ANSI

Wenn der Quellcode ANSI ist und die GUI EXE Ansi ist (set charset), dann darf da kein /GA oder /GO Schalter gesetzt werden, sonst kommt Schrott raus.

Nur bei ANSI Quellcode und OEM EXE würde man /GA setzen und sich jede Menge Ärger einhandeln

Wenn alles auf ANSI ist, wird nur noch in die DBF umgesetzt (falls nicht auch Ansi), ich vermute du hast noch ein convToAnsiCP() im Quellcode, weil es früher OEM war.

Warum /GA nach OEM konvertieren soll ist mir zwar unklar (ich hätte es anders erwartet), aber erst seit ich ANSI EXE mit ANSI Quellcode und OEM EXE mit OEM Quellcode festgelegt habe, ist der Ärger weg.
Die Workbench hat immer Ansi Quellcode oder ?

Jan hat geschrieben:Windows ist ja UTF-8, das per Char2Utf8() konvertiert

Nein, Windows hat UTF-8 Unterstützung, das mag sein, aber die Controls sind entweder WIDE (UTF-16) oder ANSI und Xbase++ kann nur die ANSI Version davon nutzen (spricht diese direkt an).

Notfalls probieren, ob convToAnsiCP() oder convToOEMCP() eine Besserung bringt. Wenn das nötig ist, dann war der Quellcode im falschen Format, oder schon konvertiert.

Hallo Hubert

Du hast Recht. Nur beim ARC muss mann noch /ga setzen. Hab ich verwechselt.

Hallo Ihr beiden,

selbstverständlich arbeite ich mit der Workbench . Und das Projekt hat keine Konvertierungen drin.

Jan

brandelh hat geschrieben: ↑Do, 16. Jan 2020 13:12Wenn alles auf ANSI ist, wird nur noch in die DBF umgesetzt (falls nicht auch Ansi), ich vermute du hast noch ein convToAnsiCP() im Quellcode, weil es früher OEM war.

Hubert,

dbf sind alle ANSI, Quellcode ist alles ANSI, Ausgabetexte sind alle ANSI.

Mach ich testweise ein ConvToAnsiCP(), dann kommt exakt das Gleiche raus wie ohne jede Konvertierung. Also "wShlen".

Ich werd irre: Mach ich ein ConToOemCP(), dann passt das. Muß ich das jetzt verstehen?

Jan

Hi Jan
Da hab ich mich auch schon gewundert, ich denk da ist bei Alaska aus Ursprungszeiten, als alles OEM war, schon ein Konvertierung ConvToAnsiCP in der Funktion drin.
Das gibt auch bei anderen Situationen, fällt mir nur nicht grad ein

So muss es sein, ist das nicht im SYS Ordner ?

Alaska anschreiben !

Hubert,

hatte ich vorhin schon direkt gemacht.

Jan

PDR 7251

Jan