Post by Stefan ReutherOK, da müsste man wissen, was für APIs da intern verwendet werden, da
kenne ich mich dann nicht aus.
Also was die GUI bzw. Formulare und Controls angeht, gibt es noch
diesen seltsamen Effekt:
Wenn ich dort Texte im Entwicklungsmodus (also im Form-Designer)
reinschreibe (Fenstertitel, Labels, Dialogboxen etc.) und die zur
Laufzeit nie anfasse, werden die bei gesetztem Haken falsch ange-
zeigt. Die Locale selbst spielt dabei offenbar gar keine Rolle -
ich habe mal in einer VM ein rein US-englisches Windows aufgesetzt,
dort werden trotzdem alle deutschen Umlaute richtig angezeigt
(wenn dieser Haken nicht gesetzt ist).
Wenn ich dagegen Texte der Controls erst zur Laufzeit setze, z.B.
einen Label mit Label1.Caption:='Grüß Gott ohne Ärger'; dann sieht
das auch bei "falscher" Locale richtig aus.
Das scheint also unterschiedlich behandelt zu werden (was auch immer
die Laufzeitbibliothek da macht, siehe unten).
Post by Stefan ReutherNaja, du könntest ein Unicode-"ä" ($00E4) und MultiByteToWideChar
reinstecken und schauen, ob das Erwartete ($E4) rauskommt. Wenn nicht
hat der Nutzer ein Locale eingestellt, das nicht zu deinem Programm
passt (kann ja auch was japanisches oder russisches sein).
Klingt interessant - damit werde ich mal herumexperimentieren. Wobei
eine falsche Locale ja gar nicht mal zu stören scheint - wenn da z.B.
"English (United States)" eingestellt ist, klappt ja trotzdem alles.
Es geht offenbar wirklich *nur* um diesen ominösen Haken bei "Beta:
Use Unicode UTF-8 for worldwide language support".
Das wäre schon schick, wenn's für dessen Abfrage (oder gar Setzen)
eine Windows-Funktion gäbe.
Hab grad mal gegoogelt: Es scheint sich um den Registry-Eintrag
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\ACP
zu handeln. Ist der Haken gesetzt, steht dort der String "65001" drin.
Wenn nicht, "1252". Das kriegt man wohl auch mit GetACP, siehe
https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getacp
bzw. die Code Page Identifiers auf
https://docs.microsoft.com/de-de/windows/win32/intl/code-page-identifiers
Manche Websites raten auch zu einem Test ähnlich wie
WideCharToMultiByte((GetACP() == 65001) ? CP_UTF8 : CP_ACP,...
Hier schreibt auch jemand, dass Dell das tatsächlich standardmäßig ankreuzt:
https://www.dell.com/community/XPS/Default-setting-for-quot-Beta-Use-Unicode-UTF-8-for-worldwide/td-p/7356751
Und Microsoft hat das Problem auch selbst erkannt:
https://support.microsoft.com/en-us/help/4490392/apps-using-legacy-crts-don-t-work-properly-when-regional-setting-is-no
Also an der Stelle könnte man wohl irgendwie ansetzen... das bringt
mich schon mal weiter.
Post by Stefan ReutherDie Idee eines UTF-8-Locale ist so dumm nicht, weil man damit in
Programmen, die 'A' Funktionen verwenden, auch Unicode darstellen kann,
und eben nicht alles auf 'W' Funktionen umarbeiten muss. Insbesondere
die Funktionen der C/C++-Standardbibliotheken sind ja mit 'A' Funktionen
definiert (fopen usw.). Deswegen ist das in Unix/Linux ja mit UTF-8
gelöst worden, und die Nerds haben das halt für Windows auch haben wollen.
Ah, *das* ist also der Grund :-)
Post by Stefan ReutherFür Anwender dürfte es keinen Grund geben, diesen Haken zu setzen, die
nerven einfach den Entwickler, dass der sein Programm anpasst :)
Wenn ich nur wüsste, wie :-) Wobei ich sagen muss, dass dieses Problem
jetzt nicht gerade Top-Priorität bei mir hat - von über 10.000 Anwendern
hatte ich bisher nur zwei, die damit steckengeblieben sind (und jetzt
weiß ich ja, wie man's beheben kann). An der Delphi-Laufzeitbibliothek
kann ich natürlich nicht herumschrauben (und Delphi 7 ist ja inzwischen
auch schon fast 20 Jahre alt - das spielt u.U. auch eine Rolle); daher
wollte ich über die Windows-eigenen Funktionen gehen, um (für mein
Programm) falsche Einstellungen herauszufinden und ggf. sogar gleich
korrigieren zu können.
Gruß Matthias.
