Windows 7: bei manchen Systemen falsches Datumsformat?

[holliesoft]

Hallo zusammen,

ich bin gerade bei der Suche über diesen Fred gestolpert.

Irgendwie habe ich die Vermutung, dass da bei einigen Windows 7-Systemen was nicht ganz sauber läuft.

Wir supporten hier auf der Arbeit einen von einem Dienstleister produzierten USB-Stick. Ich vermute, dass dort auch Delphi eingesetzt wird, denn ein kleines Testtool zur Ermittlung des Datumsformats trägt das Delphi-Icon :-)

Die Software auf dem Stick arbeitet mit einer Kopierschutzroutine, welche das Systemdatum ermittelt und bei überschreiten eines bestimmten Datums die Lizenz ungültig macht und den Content auf dem Stick löscht.

Diese Löschroutine hatte nun auf mehreren Windows7-Rechnern unserer Mitarbeiter zugeschlagen. Bei Kontrolle mit einem Testtool hatte sich dann herausgestellt, das trotz korrekter Ländereinstellungen ("Deutsch(Deutschland)") das falsche Datumsformat (nämlich mm/dd/yyyy) verwendet wurde. Erst nach Änderung auf ein anderes Land und erneutes ändern auf "Deutsch (Deutschland)" wurde das Datumsformat von der Delphi-Testapplikation (und von dem Kopierschutz) korrekt ermittelt.

Ich vermute ganz stark, dass hier bei einigen Windows 7 Konstellationen der Wurm drin ist. Hat das außer mir schon jemand irgendwo erlebt? Es wäre auch schön, wenn jemand Zugriff zu 0815-Windows 7-Komplett-PCs (aus Saturn, MM etc.) hat, und dort einfach mal eine kleine Testanwendung ausführen könnte, die einfach das Ergebnis von DateToStr ausgibt, nur um zu schauen, ob der Fehler dort auch auftritt.

Viele Grüße
ein derzeit ratloser Patrick

[Bernhard Geyer]

Im Forum von Codegear waren schon mal darüber einige Diskussionen über dieses Problem.
Schau mal dort ob dabei was rausgekommen ist.

[holliesoft]

Hi Bernhard,

danke für den Hinweis, werde mal dort schauen...

[himitsu]

Was nimmt man auch solche veränderlichen Formate für eine "genau" Auswertung?

Lösung: Man nutze einfach keinen formatierten String (weder Datum noch Sonstwas) für derartige Prüfungen.
(oder man gibt das Format selber vor, aber das ist doch umständlicher, als direkt mit TDateTime oder einem anderem gleichwertigem Datumsformat zu prüfen)


Was macht man denn, wenn jemand das Programm auf einem anderssprachigem System einsetzen will
oder wenn jemand zwar ein deutsches Windows besitzt, aber seine eigene/persönliche Einstellung bei sowas nutzt?

[holliesoft]

Zitat:

Zitat von himitsu

Was nimmt man auch solche veränderlichen Formate für eine "genau" Auswertung?

Lösung: Man nutze einfach keinen formatierten String (weder Datum noch Sonstwas) für derartige Prüfungen.
(oder man gibt das Format selber vor, aber das ist doch umständlicher, als direkt mit TDateTime oder einem anderem gleichwertigem Datumsformat zu prüfen)

Was macht man denn, wenn jemand das Programm auf einem anderssprachigem System einsetzen will
oder wenn jemand zwar ein deutsches Windows besitzt, aber seine eigene/persönliche Einstellung bei sowas nutzt?

Tja, das selbe habe ich meinen Chef auch gesagt... Ist wie gesagt keine Anwendung von mir oder meinem Arbeitgeber, sondern was gekauftes. Mir ist schleierhaft, wieso überhaupt hier eine Konvertierung DateToStr bzw. StrToDate durchgeführt wird, um ein Datum zu vergleichen. Wenn ich ein Datum in einer Konfigurationsdatei ablege, die nur von der Anwendung selbst gelesen werden soll, dann mache ich das grundsätzlich als Integer, und nicht als String.

Aber egal, was ich in diesem Betrieb sage, es interessiert eh keinen von der Führungsebene :wall:

[Sherlock]

Zitat:

Zitat von holliesoft

Aber egal, was ich in diesem Betrieb sage, es interessiert eh keinen von der Führungsebene :wall:

Du sollst das ja auch nicht Deinem Chef sagen, sondern dem Anbieter dieser fehlerhaften Software.

;)

Sherlock

[holliesoft]

Zitat:

Zitat von Sherlock

Zitat:

Zitat von holliesoft

Aber egal, was ich in diesem Betrieb sage, es interessiert eh keinen von der Führungsebene :wall:

Du sollst das ja auch nicht Deinem Chef sagen, sondern dem Anbieter dieser fehlerhaften Software.

;)

Sherlock

Tja, dumm nur, dass die Kommunikation mit dem Anbieter hier über mehrere Ebenen läuft und ich bin am unteren Ende. Aber das ist hier schon immer so gewesen *seufz*

Zurück zum Problem: Es scheint so, als würde das Problem Systeme betreffen, bei denen Windows 7 in der US-Sprach-Version installiert wurde und dann das deutsche Language Pack darüber installiert wurde... hmmm.

Bei Codegear finde ich auf die Schnelle diesen Thread zu dem Thema...

[Sherlock]

Language Pack <> Deutsches Datumsformat.
Software, die nicht korrekt das Datum ausliest ist fehlerhaft, sofern nicht in der Anleitung oder sonstwo steht, daß das Datum auf eine bestimmte Art zu formatieren ist. Das soltle doch ganz leicht zu verklickern sein. Zumal man den Fehler auf jemand anderen abwälzen kann, sowas lieben BWLer aka Entscheidungsträger. Verkauf das alles als Bug in der Fremdsoftware und alle sind glücklich, da es Null-Aufwand (=Null-Kosten) für Deine Firma bedeuetet.

Sherlock

[sh17]

Also wir kennen das Problem. Trat bis jetzt nur bei Windows 7 64bit auf. Trotz deutscher Ländereinstellung werden die globalen Variablen zur Datums-Formatierung in Delphi mit den englischen Variante belegt. Zumindest bei unserem Delphi 6. Wer jetzt nun der Schuldige ist (das alte Delphi 6 oder Windows 7), das herauszufinden hatte wir jetzt keine Lust. Man setzt nach Programmstart einfach die Variablen noch mal von Hand:

Delphi-Quellcode:

  CurrencyFormat := 3;
  NegCurrFormat := 8;
  ThousandSeparator := '.';
  DecimalSeparator := ',';
  CurrencyDecimals := 2;
  DateSeparator := '.';
  ShortDateFormat := 'dd.MM.yyyy';
  LongDateFormat := 'dddd, d. MMMM yyyy';
  TimeSeparator := ':';
  TimeAMString := '';
  TimePMString := '';
  ShortTimeFormat := 'hh:mm';
  LongTimeFormat := 'hh:mm:ss';

Und schon klappt das ganze.

Ebenso sollte man bei FOrmatanweisunge auf %m und ähnliches verzichten. Bei %m wird einem z.B. das Dollar-Zeichen anstatt des Euro untergejubelt.

//Edit
um das ganze zu verhindern sollte man DateToStr sowieso nicht verwenden, sonst lieber auf FormatDateTime setzen und alles selbst machen.

Sven

[Alter Mann]

Hi,

hatte das Problem auch, aber in anderer Art und Weise.

Windows 7/64 Ultimate US + deutsches Language Pack, trozdem war die Anzeige von Uhrzeit und Datum immer noch US.

In diesem Fall muss jeder Benutzer für sich die Einstellungen für Datum, Uhrzeit oder das Zahlenformat ändern.

Viele Grüße

[ConstantGardener]

Also die Fehler treten nicht nur mit D6 auf. Auch unter D2006 und Win7 64Bit us mit deutschem Lang.Pack sind sie noch vorhanden. Das neu setzen im Programm geht wahrscheilich, ist aber eigentlich nicht Sinn der Sache. Es sind z.B. auch die Wochtagsbezeichnungen betroffen. Einige Nutzer melden das das expliziete umschalten der Ländereinstellung auf englich und dann zurück zur deutschen Einstellung das Problem beheben kann. Reproduzieren konnte ich den Fehler aber noch nicht, da er nur auf sehr wenigen Systemen auftritt.

cu cg

[sh17]

Ja stimmt, die Wochentagsbezeichnungen sind auch betroffen, die benutzen wir aber nicht, deswegen hatte ich die nicht angepasst.

Das mit dem setzen auf englisch und zurück nach deutsch kann ich ja mal testen.

[hitzi]

Das sind nicht zufällig Siemens Rechner (Esprimo) mit vorinstallierten Win7 Professional? Geh mal in die Systemsteuerung/Zeit, Sprache Region/Datum, Uhrzeit oder Zahlenformat ändern und in dem neuen Fenster unten auf "Weitere Einstellungen". Nu geht wieder ein neues Fenster auf, wo du unten mal bitte auf "Zurücksetzen" klickst. Danach war bei uns das Datumsproblem in Verbindung mit Informix weg. Muss aber für jeden User auf dem Rechner gemacht werden.

Das Problem bei den Siemensrechnern ist, dass die bei HKCU\Control Panel\International\Locale den Wert 409 eintragen, aber eigentlich der Wert 407 da rein gehört.

[himitsu]

Zitat:

Zitat von sh17

Das mit dem setzen auf englisch und zurück nach deutsch kann ich ja mal testen.

Also, es kann praktisch sein, daß hier ein paar "fehlerhafte" oder falsch/unvollständig installierte/integrierte Languagepacks unterwegs sind, wo dann derartige Optionen nicht mit umgestellt wurden.

Beim um-/zurückstellen der Sprache würde dieses demnach dann allerdings mit angepaßt.

[sh17]

Zitat:

Zitat von hitzi

Das sind nicht zufällig Siemens Rechner (Esprimo) mit vorinstallierten Win7 Professional?

Hab auch schon Notebooks gehabt, welche nicht von Siemens sind.

[himitsu]

Delphi-Quellcode:

CurrencyFormat := 3;
  NegCurrFormat := 8;
  ThousandSeparator := '.';
  DecimalSeparator := ',';
  CurrencyDecimals := 2;
  DateSeparator := '.';
  ShortDateFormat := 'dd.MM.yyyy';
  LongDateFormat := 'dddd, d. MMMM yyyy';
  TimeSeparator := ':';
  TimeAMString := '';
  TimePMString := '';
  ShortTimeFormat := 'hh:mm';
  LongTimeFormat := 'hh:mm:ss';

Wenn ich mich nicht täuche, dann aktualisiert Delphi diese Variablen, wenn am System sowas geändert wurde.

Demnach würde es danach dann wieder Probleme geben, wenn man für irgendeine Verarbeitung ein festes Format benötigt.

[v2afrank]

Es sei denn man setzt Application.UpdateFormatSettings := false;

[holliesoft]

Hallo an alle,

danke erstmal an alle, die geantwortet haben und mir bestätigen konnten, dass das kein Einzelproblem ist.

Interessant wäre noch zu wissen, ob auch Anwendungen betroffen sind, die mit aktuelleren Delphi-Versionen (2007-2010) kompiliert worden sind.

Sobald ich den nächsten Fall auf meinem Tisch habe, lasse ich mal ein kleines Testprogramm, das ich mit einem aktuellen Lazarus-Snapshot kompiliert habe, auf einem betroffenen System laufen. Wenn Lazarus auch die falschen Settings für das ShortDateFormat zieht, dann liegt der Fehler für mich zu 100% bei den betroffenen Windows 7-Systemen und nicht bei Delphi (Trotzdem: sich auf korrekte System-Einstellungen zu verlassen ist ohne Frage "pfui". Auch ein deutsches System kann bewusst ein anderes Datumsformat eingestellt haben).

[sh17]

Zitat:

Zitat von v2afrank

Es sei denn man setzt Application.UpdateFormatSettings := false;

Interessant - kannte ich noch nicht ;-)

[himitsu]

Zitat:

Zitat von holliesoft

Interessant wäre noch zu wissen, ob auch Anwendungen betroffen sind, die mit aktuelleren Delphi-Versionen (2007-2010) kompiliert worden sind.

Zitat:

Zitat von sh17

Interessant - kannte ich noch nicht ;-)

Ich och nicht, aber da ich mich nicht auf bestimmte Systemeinstellungen einschränke, hab ich sowas auch nie gesucht.

Ich finde es eh etwas "schlimm", wenn man in seinem Programm den "Willen" des Nutzers ignoriert und vom System abweichende Einstellungen nutzt, bzw. nur bestimmte Einstellungen erlaubt, womit dann das Programm nicht auf allen Systemen läuft, wie man hier am Thema ja sehr gut erkennen kann.

Delphi-Quellcode:

ShortDateFormat := TranslateDateFormat(GetLocaleStr(DefaultLCID, LOCALE_SSHORTDATE, 'm/d/yy'));

und

Delphi-Quellcode:

function TranslateDateFormat(const FormatStr: string): string;
var
  I: Integer;
  L: Integer;
  CalendarType: CALTYPE;
  RemoveEra: Boolean;
begin
  I := 1;
  Result := '';
  CalendarType := StrToIntDef(GetLocaleStr(GetThreadLocale,
    LOCALE_ICALENDARTYPE, '1'), 1);
  if not (CalendarType in [CAL_JAPAN, CAL_TAIWAN, CAL_KOREA]) then
  begin
    ...

Delphi-Quellcode:

function GetLocaleStr(Locale, LocaleType: Integer; const Default: string): string;
{$IFDEF MSWINDOWS}
var
  L: Integer;
  Buffer: array[0..255] of Char;
begin
  L := GetLocaleInfo(Locale, LocaleType, Buffer, Length(Buffer));
  if L > 0 then SetString(Result, Buffer, L - 1) else Result := Default;
end;
{$ENDIF}
{$IFDEF LINUX}
begin
  Result := Default;
end;
{$ENDIF}

GetLocaleStr = GetLocaleInfo
Delphi nutzt hier fast direkt die WinAPI.

Nun gibt es hier 2 Fälle entweder GetLocaleInfo liefert keinen String und es wird das Default genutzt oder GetLocaleInfo liefert wirklich einen anderen Formatstring.

In beiden Fällen sollte Lazarus ähnlich arbeiten und denmach auch ähnlich reagieren.

[sh17]

OT

Zitat:

Zitat von himitsu

Ich finde es eh etwas "schlimm", wenn man in seinem Programm den "Willen" des Nutzers ignoriert und vom System abweichende Einstellungen nutzt, bzw. nur bestimmte Einstellungen erlaubt, womit dann das Programm nicht auf allen Systemen läuft, wie man hier am Thema ja sehr gut erkennen kann.

Na da bin ich nicht ganz der gleichen Meinung. Ich hätte schon gern die Kontrolle über meine Software, eben um solche Probleme mit neuen Windowssystemen zu umgehen. Mit jedem neuen Windows gab es wieder was neues, was geändert wurde und was Auswirkungen auf unser Produkt hatte. Da mach ich lieber alles selbst und weiß, es geht überall, weil ich sage, was zu tun ist und nicht irgend eine Ländereinstellung oder Sortierroutine (einfach mal bei Google "compare string works different" eingeben) die sich auf einmal anders verhält.

Bei tausend und mehr Kunden artet das in nicht endenden Support aus. Der wird mir nicht bezahlt. Jedem erzähl ich dann, stellen Sie mal auf englisch und dann auf deutsch zurück, dann gehts. 80% wissen erst mal nicht, was ich überhaupt von ihnen will. Das ist einfach Zeit, die ich nicht haben möchte, also lieber das Rad selbst bauen. Windows ist mir relativ Schnuppe - meinetwegen kann da wer weis was für ein System drunter liegen, hauptsache das Produkt funktioniert.

In diesem Sinne... (Sorry fürs Luft ablassen)

[himitsu]

Zitat:

Zitat von sh17

Na da bin ich nicht ganz der gleichen Meinung. Ich hätte schon gern die Kontrolle über meine Software, eben um solche Probleme mit neuen Windowssystemen zu umgehen.

Hast du doch auch?

Erstmal kannst du für Dinge wo das Format wirklich feststehn muß immernoch den Format-Parameter nutzen.

Code:

function FormatDateTime(const Format: string; DateTime: TDateTime;
  const [b]FormatSettings: TFormatSettings[/b]): string;

Und ansonsten arbeitet man Programmintern einfach nicht mit solchen Werten,
sondern nutzt Formate, welche eben nicht systemabhängig sind.

Delphi-Quellcode:

If Now < StrToDate('01.01.2011') then

Delphi-Quellcode:

If Now < 40544 then

Jetzt wird das Datum nur noch zur Anzeige entsprechend Formatiert und schon kann der Benutzter das Datum so sehn, wie es ihm gefällt und wie es demnach im System eingestellt ist.

Tut mir Leid, aber ich sehe absolut keinen Grund, abgesehn von einer "lesbaren" Form der Datenspeicherung, um solche Werte formatiert zu verarbeiten.

Also wenn irgendwo eine bestimmte Einstellung des Systems unnötiger Weise "vorgeschrieben" ist, damit auch alles ordnungsgemäß läuft, dann ist das meiner Meinung nach ein Programmfehler und nicht ein Fehler des Systems, welches auch einfach mal anders eingestellt sein kann.

Derartige Einstellungen gehören zum UI (User Interface) und demnach auch nur in die Anzeige ... in der Internen Programmverarbeitung hat sowas nichts zu suchen.
Oder warum wird sonst schon seit Jahren geprädigt, das Verarbeitung und Anzeige getrennt sein sollten?

[sh17]

Das ich formatierte Daten nicht bei der internen Programmverarbeitung nutze versteht sich ja von selbst - gehört eigentlich zum Grundwissen.

Aber wenn mich der x-te anruft, warum denn auf seinem neuen Client plötzlich der Kalender englische Wochentage anzeigt und das Datum anders formatiert ist, oder der Dezimalseparator auf einmal ein Punkt ist, oder der Datenbankindex defekt ist, weil compareString nicht korrekt nach deutschen Gegebenheiten vergleicht, ...dann hab ich darauf keinen Bock. Dann häng ich Windows komplett ab und mach alles selbst. Nur darum gehts: S' muss gehn

[himitsu]

Wenn ich ein englisches Windows hab, warum sollte dann ein Programm nicht auch englische Formate nutzen?
Ein Amerikaner nutzt ja auch sonst den Punkt als Komma ... also könnte ihn ein Komma als Dezimaltrennzeichen genauso verwirren.

Aber OK, wenn der Rest der GUI deutsch ist, dann ist es richtig, wenn man dort kein englisch anzeigt.

Zitat:

Zitat von sh17

oder der Datenbankindex defekt ist, weil compareString nicht korrekt nach deutschen Gegebenheiten vergleicht,

Dann ist die Berechnung des Index eben fehlerhaft.

[sh17]

Zitat:

Zitat von himitsu

Dann ist die Berechnung des Index eben fehlerhaft.

Nein,das Verhalten von CompareString wurde ab Windows Vista verändert. Ich hatte genug Diskussionen dazu mit dem "Verantwortlichen" bei MS. Das Ergebnis bei MS - vorher war es falsch, jetzt ist es richtig. So kann sich auch rausreden.

Aber egal, mach mer Schluss mit dem OT, bevor der Mod noch den Thread schliesst.

[holliesoft]

Hallo nochmal,

falls es jemand interessiert:

Testprogramm mit Delphi2007 ==> US-Format
Testprogramm mit aktuellem Lazarus-Snapshot (mit FPC 2.4.1) ==> US-Format

Gruß,
Patrick

[cs.rumpelstilzchen]

Hallo Leutz!

Ich hab das gleiche Problem auf ASUS EeeTop2002-Systemen festgestellt. Scheint tatsächlich mit der Vorinstallation zu tun zu haben! Nach umstellen der Ländereinstellungen (auf z.B. Österreich) und sofortigem zurückstellen auf Deutschland, geht dann alles, wie es sein soll! Das gleiche passiert, wenn ich die Ländereinstellungen für Deutschland in der Systemsteuerung einfach "zurücksetze"!
Ist natürlich großer Mist! Vor allem für den Support... :wall:

Ich habe mir die Mühe gemacht, eigene Funktionen für Datums/Zeit und Währungsumwandlungen zu programmieren.

Ich deklariere mir eine globale Variable:

Delphi-Quellcode:

  // Formateinstellungen für Datum/Zeit-Funktionen
  // Damit Umwandlungen wie 'DateTimeToStr'
  // unabhängig von den Ländereinstellungen des
  // Systems funktionieren! z.B. bei Win7!!!!!
  // =============================================
  gFS : TFormatSettings;

Bei Programmstart initialisiere ich diese auf deutsches Format...

Delphi-Quellcode:

  // Deutsche Format-Settings holen!
  GetLocaleFormatSettings(1031, gFS);

...und benutze sie dann in meinen Funktionen:

Delphi-Quellcode:

function MyDateTimeToStr(const Datum : TDateTime) : String;
begin
  Result := DateTimeToStr(Datum, gFS);
end;

function MyTimeToStr(const Time : TTime) : String;
begin
  Result := TimeToStr(Time, gFS);
end;

function MyDateToStr(const Datum : TDateTime) : String;
begin
  Result := DateToStr(Datum, gFS);
end;

function MyStrToDateTime(const szDatum : String) : TDateTime;
begin
  Result := StrToDateTime(szDatum, gFS);
end;

function MyStrToDate(const szDatum : String) : TDateTime;
begin
  Result := StrToDate(szDatum, gFS);
end;

function MyStrToTime(const szTime : String) : TDateTime;
begin
  Result := StrToTime(szTime, gFS);
end;

function MyTryStrToDateTime(const szDatum: string; var Datum: TDateTime): Boolean;
begin
  Result := TryStrToDateTime(szDatum, Datum, gFS);
end;

function MyTryStrToDate(const szDatum: string; var Datum: TDateTime): Boolean;
begin
  Result := TryStrToDate(szDatum, Datum, gFS);
end;

function MyTryStrToTime(const szTime: string; var Datum: TDateTime): Boolean;
begin
  Result := TryStrToTime(szTime, Datum, gFS);
end;

Ich habe mir ein kleines Testprogramm gebastelt: :coder2:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  FormatSettings: TFormatSettings;
  var MyLCID : Integer;
begin
  GetLocaleFormatSettings(SysLocale.DefaultLCID,FormatSettings);
  Label1.Caption := '(' + IntToStr(SysLocale.DefaultLCID) + ') -> ' +DateTimeToStr(now, FormatSettings);

  MyLCID := GetUserDefaultLCID;
  GetLocaleFormatSettings(MyLCID,FormatSettings);
  Label8.Caption := '(' + IntToStr(MyLCID) + ') -> ' +DateTimeToStr(now, FormatSettings);

  GetLocaleFormatSettings(1031,FormatSettings);
  Label2.Caption := '(' + IntToStr(1031) + ') -> ' + DateTimeToStr(now, FormatSettings);

  Label3.Caption := '() -> ' + DateTimeToStr(now);
end;

Interessant ist in diesem Zusammenhang folgendes:
Es machte auf den getesteten Windows 7 - Systemen (3 konnte ich testen) einen Unterschied, ob ich die SysLocale.DefaultLCID (->ergibt US-Format) oder die GetUserDefaultLCID (-> ergibt deutsches Format) benutze. Es ist nur die SysLocale.DefaultLCID betroffen! Anscheinend benutzt Delphi diese in den eigenen Funktionen! Die über GetUserDefaultLCID bezogene LCID ist immer korrekt! :gruebel:

Vermutlich ist die Lokalisierung der getesteten Windows 7-Systeme nur auf User-Ebene erfolgt...
Shit happens! :zwinker:

[mschaefer]

Moin moin,

Zum Beispiel bein Win64 auf Asus-Altec und das haut dann 'strtofloat' in Exceptions.
Solange das Programm deutsch spricht bekommt es also obigen Weg.

Grüße in die Runde

[RWarnecke]

Hallo zusammen,

ich habe das gleiche Problem. Meine Berechnung erfolgt noch komplett richtig in der jeweiligen Form, wie ich es in den Ländereinstellungen vorgegeben ist. Versuche ich aber nun mit FormatDateTime('dd.mm.yyyy', date) das Ergebnis als String auszugeben, dann gibt es eine Exception.
Da ich mit Datumswerten rechnen muss, hat jemand einen Vorschlag, wie man solche Sachen umgehen kann ?

[mschaefer]

Mir fällt da nur ein die Constanten entsprechend einer Spracheinstellung im Programm zu definieren.

Wenn das ein Windows Problem ist, weiss man kaum auf welchen Rechner man trifft. Zumal ich hier ein
gut geupdatetes Windows 7 habe und es auch keinen Hang zur Autokorrektur gibt. Eigentlich müßten auch
die Delphi 2010´er das Problem haben. Kann das mal einer Testen?

Grüße // Martin


PS: Ein kleiner Nebeneffekt:

Habe hier ein DBEdit mit Floatfeld als Datenbankbasis in FB.
Das Ding akzeptiert keine Kommas, dafür aber Punkte als Anteilstrenner.

[RWarnecke]

Eine andere Möglichkeit ist beim FormatDateTime die folgende Zeile zu benutzen :

Delphi-Quellcode:

FormatDateTime('ddddd', now);

Dabei wird dann das Datum so angezeigt, wie die Ländereinstellungen vom System es rausgeben. Damit kann man dann wieder auch ohne bedenken ein StrToDate durchführen.

Probiert es mal aus und gebt mal Rückmeldung, ob es funktioniert.

[mschaefer]

Das leidliche daran ist, dass man auf Fremdkomponenten kaum Einfluss hat. Es sei den man möchte für alles noch Codewartung machen.
Wahrscheinlich ist ein Dialog zum Umstellen der Datum und Währungseinstellungen von Windows eher die Lösung

Grüße // Martin

[sx2008]

Zitat:

Zitat von cs.rumpelstilzchen

Es machte auf den getesteten Windows 7 - Systemen (3 konnte ich testen) einen Unterschied, ob ich die SysLocale.DefaultLCID (->ergibt US-Format) oder die GetUserDefaultLCID (-> ergibt deutsches Format) benutze. Es ist nur die SysLocale.DefaultLCID betroffen! Anscheinend benutzt Delphi diese in den eigenen Funktionen! Die über GetUserDefaultLCID bezogene LCID ist immer korrekt! :gruebel:
Vermutlich ist die Lokalisierung der getesteten Windows 7-Systeme nur auf User-Ebene erfolgt...

Das wäre doch ein Ansatz, wie man das Problem richtig lösen kann, anstatt nur falsche Korrekturen anzubringen.
(Diese Rumgefrikle wie z.B. in Beitrag #9 kann doch nicht die Lösung sein.)
Wenn die beiden LCIDs unterschiedlich sind, bekommt der Benutzer einen Hinweis was er tun muss um das zu ändern.

[RWarnecke]

Zitat:

Zitat von sx2008

Das wäre doch ein Ansatz, wie man das Problem richtig lösen kann, anstatt nur falsche Korrekturen anzubringen.
(Diese Rumgefrikle wie z.B. in Beitrag #9 kann doch nicht die Lösung sein.)
Wenn die beiden LCIDs unterschiedlich sind, bekommt der Benutzer einen Hinweis was er tun muss um das zu ändern.

Im gewissen Sinne, gebe ich Dir recht. Nur wenn der Anwender ein englisches Windows hat, kann er ja nicht nur für ein Programm auf Deutsch umstellen. Da läuft man doch Gefahr, dass irgendein anderes englische Programm dann wieder nicht funktioniert.

[monello_ch]

Hallo zusammen

Seit ich mit Windows 7 64 Bit arbeite, habe ich das Problem, dass der DecimalSeparator nicht korrekt von den Voreinstellungen übernommen wird. Ländereinstellungen und Sprachvorgaben sind aber korrekt, mehrmals kontrolliert.

Nun hatte ich aus der Not heraus beim Programminit einfach "DecimalSeparator := '.'" gesetzt, damit ich trotzdem vernünftig entwickeln konnte, wobei einige Controls für die Dateneingabe trotzdem noch auf dem ',' beharrten, jedoch den Dezimalpunkt anzeigten. Mühsam.

Soeben die Lösung gefunden, mehr zufällig: Systemsteuerung->Region und Sprache->Datum, Uhrzeit oder Zahlenformat ändern->Weitere Einstellungen...->und auf allen Tabs (Zahlen, Währung, Uhrzeit, Datum) den Button "zurücksetzen" gewählt. Optisch ändert sich gar nix, es war ja schon vorher korrekt für meine Einstellung "Deutsch (Schweiz)", jedoch habe ich jetzt plötzlich auch im Delphi die korrekten Vorgaben, und alle Controls mit Datum / Zahlen verhalten sich nun endlich erwartungsgemäss.

Uff, was bin ich froh geht das nun endlich ohne irgendwelche Hacks...

[himitsu]

Es scheint einfach 2 Orte der Datenspeicherung zu geben
oder einige Auslesefunktionen scheinen einen Defaultwert rauszurücken, wenn was nicht stimmt oder fehlt.

Ich würde eher zu Letzterem tendieren (da hier ein Grund liegen könnte, warum nur nichtenglische "Ausländer" Probleme haben und dieses auch in den englischen Testphasen nicht auffiehl).

Jedenfalls scheint ein Zurücksetzen oder kurzes Auf-englisch-und-dann-auf-deutsch-zurückstellen die/alle Werte dann richtig zu setzen und das Problem zu beheben.

[RWarnecke]

Hallo,

es gab mal eine ganze Serie von Notebooks und glaube auch Rechner von Fujitsu. Da trat das Problem auch mit dem Datumsformat auf. Das lag daran, das die Ländereinstellungen im System nicht richtig gespeichert wurden. Da gab es nur die Abhilfe, dass man die Ländereinstellungen zurücksetzte oder eine andere Einstellung speicherte und dann wieder auf die richtige Einstellung zurückging. Ich habe das ganze dann mit ein bisschen Sourcecode abgefangen. Danach funktionierte es einwandfrei.
Wenn interesse besteht, kann ich diesen hier heute Abend dranhängen.

[generic]

Es ist ein bekannter Windowsbug.

Hier ist noch ein Beitrag über das Thema:
http://www.delphipraxis.net/152005-w...instellun.html

[GunterM]

Hallo, allerseits,

ich kann euch von einer gleichen Situation berichten: Neues Notebook Fujitsu, win7 prof 64 bit. Eine mit Delphi 2010 programmierte Anwendung (Daten aus MS SQL-Server 2008) lief auf dem Vorgänger (32-Bit Vista Prof.) sauber, zeigte in der IDE auch korrekte Formatierungen bei Datums- und Währungswerten sowie Tausender- und Dezimaltrennzeichen an. Sobald ich das Ding compiliert hatte, waren alle Formatierungen in EN-US.

Lösung in euren Beiträgen gefunden - Zurücksetzen der Ländereinstellungen. Danke!

Da das Thema Ländereinstellungen offensichtlich viele beschäftigt: Hab bei Marco Cantu im eHandbook D2010 eine Passage gefunden, dass die Kombi D2010 / Win7 da wesentliche Neuerungen mitbringt.

[mkinzler]

Dieses Problem scheint bei manchen Win7 Installationen vorzukommen, liegt aber an Windows. Dort ist beim Benutzer kein Format hinterlegt. (Sollte durch explizites Setzen beim Benutzer erfolgen)