Falsches ShortDateFormat unter Windows 7

[trashcandesign]

Moin,

wir formatieren unsere Datums-Felder mit dem ShortDateFormat um die Datumsanzeige entsprechend den Windowsländereinstellungen zu formatieren.

Bisher hat das auch wunderbar funktioniert.
Nun habe ich heute ein Windows 7 32Bit aufgesetzt und plötzlich gab mir das ShortDateFormat M/d/yyyy zurück, obwohl in den Ländereinstellungen das Format auf dd.MM.yyyy gesetzt wurde.


Das
GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SSHORTDATE, PAnsiChar(test), 20); hat mir das richtige Ergebnis geliefert, aber

GetLocaleFormatSettings(LOCALE_USER_DEFAULT, Formatsettings); wieder das falsche?!


Soweit ich das verstanden habe hat GetLocaleFormatSettings GetThreadLocale als DefaultLCID gesetzt.
Und die ThreadLocale gab dann wieder das Ami-Format zurück. Warum auch immer.

ich habe dann auf der Seite nachgelesen, dass man mal die Lokalen Ländereinstellungen ändern und wieder zurück setzen soll. Das hat dann auch bei mir funktioniert und unser Programm hat dann wieder das richtige Format ausgegeben.

Das Windows 7 war eine Multi-Language Version, die dann bei der Installation auf Deutsch gesetzt wurde.
Bei einer rein deutschen Version ist dieses Problem nicht aufgetreten.
Wir setzen momentan Delphi 2006 ein.

Nun meine Frage: Hat das Problem schon mal jemand gehabt? Weiß vielleicht jemand, woran das Problem genau liegt und ob das mit der aktuellen Delphi-Version auch noch auftritt?

Und warum gibt IsValidLocale(LOCALE_USER_DEFAULT, LCID_INSTALLED) 0 zurück?

[berens]

Hallo zusammen und sorry für das Ausgaben dieses alten Threads.

Da die Thematik ja leider immer aktueller wird, würde mich interessieren, wie man das Problem diagnostizieren oder Lösen kann, da ich bei meinen Installationen kurzfristig eine Lösung dafür anbieten muss; speziell Zugeschnitten auf die deutschen Kunden.

Das Problem trifft mittlerweile auf fast allen PC von großen Händler oder innerhalb großer Firmen auf, da diese meistens -wie erwähnt- die Multilingual-Version von Windows 7 haben.

Meine Idee wäre es, die Ländereinstellungen auszulesen. Wenn diese = Deutsch, dann versuche ob von irgend einem festen Datum mit Zeit der String für ShortDateFormat = dem String für dd.mm.yy(yy?) für dieses Datum ist, und der String für die Uhrzeit (z.B. 13 Uhr wegen am/pm) von ShortTimeFormat = HH:nn ist, im Sinne von

if FormatDateTime('t', 13/24) = FormatDateTime('HH:nn', 13/24) then begin ...

Wenn nicht, frage den Benutzer ob die Ländereinstellungen ein Mal kurz auf Englisch (USA) und dann wieder auf Deutsch gesetzt werden sollen, damit im kompletten System die selben Einstellungen gelten.


Alternativ bin ich auch für andere Ideen und Denkansätze sehr dankbar, wie Ihr das löst. Wie bist Du verblieben, trashcandesign?

Die Kunden wundert's halt, dass Datum und Zeit in einigen Programmen auf Englisch ist...


Mir ist klar, dass hier im Forum dieses Problem schon oft diskutiert wurde (Lösung: Ländereinstellungen manuell auf Englisch und wieder zurück), aber die Frage ist, ob man dem Benutzer anbieten sollte, dieses erkannte Problem automatisch lösen zu lassen.

http://www.delphipraxis.net/148784-w...umsformat.html
http://www.delphipraxis.net/152005-w...instellun.html

Edit 1: Hat jemand im Kopf, ob und wie ich dieses manuelle Umstellen über Delphi simulieren kann? Mit SetLocaleFormatSettings oder wie? Naja, mal SuFu nutzen...

Edit 2: Hier im Forum nix sinnvolles gefunden. Google bringt HKEY_USERS\.DEFAULT\Control Panel\International zu Tage. Ich habe leider jetzt kein betroffenes System greifbar um das zu testen, aber es könnte sein, dass hier oder in einem anderen Key das abweichende Format notiert ist. Dann würde es ja langen, die Einstellungen in der Registry zu kopieren. Hat jemand ein MUI System mit dem genannten Problem und kann mir sagen, ob HKEY_USERS\.DEFAULT\Control Panel\International von HKEY_CURRENT_USER\Control Panel\International unterschiedliche Formate nutzen?

[mjustin]

Eventuell hilft dieser Thread weiter:

Should GetThreadLocale become deprecated?
https://forums.embarcadero.com/threa...60433&tstart=0

Zitat:

As discussed on Stackoverflow, GetThreadLocale returns different value
than GetUserDefaultLCID
(http://stackoverflow.com/questions/1...serdefaultlcid).
As one of the answers said, it occurs because Microsoft seems to be in
the process of deprecating the Locale ID in favor of the Locale Name. So
should Delphi reflect this process by deprecating GetThreadLocale?

Die Lösung wäre getuserdefaultlcid zu verwenden, wenn ich es richtig gelesen habe.

[Darlo]

Soweit ich weiss kann man auch für das eigene Programm die Einstellungen unabhängig von Windows vornehmen. Meine einfach ins create des Hauptforms folgendes rein setzten:

Code:

DateSeparator := '.'; 
ShortDateFormat := 'dd.mm.yyyy'; 
LongDateFormat := 'dddd, dd.mmmm.yyyy'; 
DecimalSeparator := ','; 
ThousandSeparator := '.'; 
CurrencyString := '€';

[himitsu]

Zitat von Darlo:

Soweit ich weiss kann man auch für das eigene Programm die Einstellungen unabhängig von Windows vornehmen. Meine einfach ins create des Hauptforms folgendes rein setzten:

Aufpassen: Wenn zur Laufzeit die Systemeinstellungen geändert werden, dann reagieren Delphi-Programme gerne mal darauf und überschreiben diese Werte wieder.
Denn Windows sendet dabei eine systemweite Notification (Message).

Wenn möglich stattdessen eine eigene Variable TFormatSettings erstellen und diese direkt verwenden.
Viele Funktionen unterstützen einen entsprechenden Parameter, siehe z.B. TimeToStr.

Zitat von Darlo:

Code:

DateSeparator := '.'; 
ShortDateFormat := 'dd.mm.yyyy'; 
LongDateFormat := 'dddd, dd.mmmm.yyyy'; 
DecimalSeparator := ','; 
ThousandSeparator := '.'; 
CurrencyString := '€';

In neueren Delphis bitte auf das hören, was einem der Compiler dazu sagt.
var DecimalSeparator: Char deprecated 'Use FormatSettings.DecimalSeparator';

[Luckie]

Zitat von Darlo:

Soweit ich weiss kann man auch für das eigene Programm die Einstellungen unabhängig von Windows vornehmen. Meine einfach ins create des Hauptforms folgendes rein setzten:

Code:

DateSeparator := '.'; 
ShortDateFormat := 'dd.mm.yyyy'; 
LongDateFormat := 'dddd, dd.mmmm.yyyy'; 
DecimalSeparator := ','; 
ThousandSeparator := '.'; 
CurrencyString := '€';

Und warum bist du dir so sicher, dass mein Datumsformat dd.mm.yyyy ist?

[Darlo]

Werde ich beachten...

[berens]

Zitat:

Die Lösung wäre getuserdefaultlcid zu verwenden, wenn ich es richtig gelesen habe.

Das Problem an der Sache ist ja, dass sowohl FormatDateTime wie auch Komponenten (TMonthCalendar, TDateTimePicker) das englische Format übernehmen, obwohl überall in Windows das deutsche Format zu sehen ist. Z.B. Uhr und Datum in der Taskleiste: alles Deutsch.

Dementsprechend möchte ich mich dem Format anpassen, das die Uhr und das Datum in der Taskleiste verwenden. Damit kann ich einerseits prüfen, ob ShortTimeFormat das korrekte Format zurück gibt, andererseits zwinge ich dem Benutzer nicht automatisch das HH:nn Format auf, wenn Leute wie Luckie da etwas getuned haben

Da FormatDateTime und die angesprochenen Komponenten, sagen wir, "High-Level"-Komponenten sind (also fix-und-fertig Programmiert, da kann/soll/will ich nichts mehr dran ändern), bringt mit die Lösung mit "getuserdefaultlcid" nichts.

"ShortDateFormat := 'dd.mm.yyyy'; " etc. Lösen zwar mein Problem, und das der traditionellen deutschen Kunden, aber spätestens bei den ausländischen Kunden gibt es dann -logischerweise- Probleme.

Ich versuche mir gerade eine "Testversion" von Windows 7 zu beschaffen, um das Problem nachzustellen; vielleicht kann man ja wirklich über die Registry-Einträge etwas machen...

[himitsu]

Es ist halt ein Fehler in Windows, welcher sich durch eine schlechte Konfiguration zeigt.

Der beste Weg ist also dieses in Windows zu beseitigen, anstatt nachträglich drann rumzudoktern.