Regionale Einstellungen

[Cogito]

Hallo zusammen,

in verwende in meinem Programm ein datagrid, bei welchem eines der Felder auf einem decimal field in SQL Server 2008 basiert. Auf manchen Rechnern kann man ein Komma als dezimal trenner verwenden, auf manchen aber auch nicht. Ich dachte bisher immer das würde einzig von den Region-Einstellungen unter Windows abhängen, aber mein Kollege hier hat z.B. auch ein Komma als Trenner eingestellt, kann dies aber nicht in Dezimalfeldern verwenden. Es geht darum, das Kunden gerne immer ein Komma verwenden möchten, weil dies im numerischen Block der Tastatur verfügbar ist und die Eingabe von Dezimalzahlen dadurch sehr viel schneller vonstatten gehen kann. Kann mir jemand sagen, ob und wie ich in Delphi veranlassen kann, das grundsätzlich immer das Komma als Dezimaltrennzeichen verwendet wird?

[ASM]

Zitat:

Zitat von Cogito (Beitrag 1165592)

Kann mir jemand sagen, ob und wie ich in Delphi veranlassen kann, das grundsätzlich immer das Komma als Dezimaltrennzeichen verwendet wird?

Hiermit sollte es vermutlich gehen:

Code:

procedure SetDecimalSeparator(Ch: Char);
var
  DefLCID: LCID;
  Buffer: LPSTR;
begin
  Application.UpdateFormatSettings := True;
  StrPCopy(Buffer, Ch);
  DefLCID := GetThreadLocale;
  if SetLocaleInfo(DefLCID, LOCALE_SDECIMAL, Buffer) then
    DecimalSeparator := StrPas(Buffer)[1];
  Application.UpdateFormatSettings := False;
end;

procedure TForm1.FormActivate(Sender: TObject);
begin
  SetDecimalSeparator(',');
end;

[khh]

schade, hätte ich auch gebrauchen können, aber Lazarus kennt:


Application.UpdateFormatSettings

ledier nicht :-(

[DeddyH]

Kennt Lazarus denn die globale Variable Decimalseparator aus SysUtils?

[khh]

ja, die kennt Lazarus

[jaenicke]

Solange Lazarus die Einstellungen nicht zwischendrin wiederherstellt kannst du das auch weglassen. Bei Delphi dient das dazu, dass die gesetzten Einstellungen auch bei einer Aktualisierung beibehalten werden.

[shmia]

Zitat:

Zitat von Cogito (Beitrag 1165592)

... Ich dachte bisher immer das würde einzig von den Region-Einstellungen unter Windows abhängen

Das tut es auch.
Es sei denn es handelt sich um Window Vista oder Windows 7.
Dann kann es passieren, dass Delphi-Programme alle regionalen Einstellungen als English(USA) auslesen, obwohl in der Systemsteuerung Deutsch(Deutschland) eingestellt ist.

Dann muss man auf Englisch umschalten, abspeichern und wieder auf Deutsch umschalten und abspeichern. (Natürlich für jeden Windows User)

[himitsu]

Zitat:

Zitat von shmia (Beitrag 1165642)

Dann kann es passieren, dass Delphi-Programme alle regionalen Einstellungen als English(USA) auslesen, obwohl in der Systemsteuerung Deutsch(Deutschland) eingestellt ist.

Da es nicht richtig (nur teilweise) auf Deutsch eingestellt ist und der Teil vergessen wurde zu ändern, wo Delphi seine Informationen herbekommt.

[bernhard_LA]

ist doch ein bekannter Windows Bug, verfügbar in XP Vista und WIN 7 :

um den richtig Ländercode auslesen zu können zuerst die Sprache in der Systemsteuerung von Deutsch auf Isländisch (oder ...) stellen speichern und dann von Isländisch zurück auf Deutsch. Dann kann man auch Deutsch mit den Ländereinstellungen auslesen.

[Cogito]

Zitat:

Zitat von ASM (Beitrag 1165613)

Zitat:

Zitat von Cogito (Beitrag 1165592)

Kann mir jemand sagen, ob und wie ich in Delphi veranlassen kann, das grundsätzlich immer das Komma als Dezimaltrennzeichen verwendet wird?

Hiermit sollte es vermutlich gehen:

Code:

procedure SetDecimalSeparator(Ch: Char);
var
  DefLCID: LCID;
  Buffer: LPSTR;
begin
  Application.UpdateFormatSettings := True;
  StrPCopy(Buffer, Ch);
  DefLCID := GetThreadLocale;
  if SetLocaleInfo(DefLCID, LOCALE_SDECIMAL, Buffer) then
    DecimalSeparator := StrPas(Buffer)[1];
  Application.UpdateFormatSettings := False;
end;

procedure TForm1.FormActivate(Sender: TObject);
begin
  SetDecimalSeparator(',');
end;

Dieser Code funktioniert bei mir nicht.
In der Zeile

Code:

if SetLocaleInfo(DefLCID, LOCALE_SDECIMAL, Buffer) then

meldet mir der Compiler einen Fehler: Inkompatible Typen 'AnsiChar' und 'Char'

Kannst du deine Funktion mal testen?

[himitsu]

Wieso verwendet man hier auch LPSTR? :wall:

Zitat:

Delphi-Quellcode:

LPSTR = PAnsiChar;

Im MSDN (SetLocaleInfo) steht doch ausdrücklich LPCTSTR. :!:

Oder man nimmt einfach PChar. :roll:


PS: Sowas ist übrigens einer der Gründe, warum es beim Umstieg auf Unicode (Delphi 2009 und höher) so viele Probleme gab ... schlechter/fehlerhafter Code.


[add]

Delphi-Quellcode:

procedure SetDecimalSeparator(Ch: Char);
begin
  Application.UpdateFormatSettings := True;
  if SetLocaleInfo(GetThreadLocale, LOCALE_SDECIMAL, PChar(String(Char))) then
    DecimalSeparator := Ch;
  Application.UpdateFormatSettings := False;
end;

[Cogito]

OK, vielen Dank.
Das Problem scheint aber doch woanders zu liegen. Der User möchte nämlich im numerischen Block der Tastatur das Komma benutzen können, wenn er numerische Werte in die Applikation eingibt. Jetzt ist mir aufgefallen, dass es Unterschiede im Num-Block bezüglich der Tastenbelegung gibt. Bei deutschen Tastaturen ist dort ein Komma, bei anderen ein Punkt. Und wenn sie auf den Punkt klicken ist das natürlich nicht erlaubt in einem numerischen Feld. Hat hier jemand eine Idee? Ich könnte mir vorstellen dass es helfen könnte, sobald jemand auf den Punkt klickt dieses automatisch in ein Komma umzuwandeln, aber ich hab ehrlich gesagt keine Ahnung...

[shmia]

Zitat:

Zitat von Cogito (Beitrag 1166805)

Bei deutschen Tastaturen ist dort ein Komma, bei anderen ein Punkt

Jemand, der eine Tastatur mit US-Zeichenbelegung angeschlossen hat, wird doch wahrscheinlich auch English (USA) als Regionalsetting eingestellt haben.
Dann passt die Tastatur zur Einstellung.

Wenn es wirklich wichtig ist, dass ein deutschsprachiger User an einem Rechner mit englischer Tastatur effizient arbeiten kann, dann wäre die absolut billigste Lösung zusätzlich eine deutsche Tastatur (Kosten: 8 Euro) anzuschliesen.
Ich würde mich hier nicht auf ein Gemurkse auf Softwarebene einlassen.

[Cogito]

Zitat:

Zitat von shmia (Beitrag 1166808)

Zitat:

Zitat von Cogito (Beitrag 1166805)

Bei deutschen Tastaturen ist dort ein Komma, bei anderen ein Punkt

Jemand, der eine Tastatur mit US-Zeichenbelegung angeschlossen hat, wird doch wahrscheinlich auch English (USA) als Regionalsetting eingestellt haben.
Dann passt die Tastatur zur Einstellung.

Wenn es wirklich wichtig ist, dass ein deutschsprachiger User an einem Rechner mit englischer Tastatur effizient arbeiten kann, dann wäre die absolut billigste Lösung zusätzlich eine deutsche Tastatur (Kosten: 8 Euro) anzuschliesen.
Ich würde mich hier nicht auf ein Gemurkse auf Softwarebene einlassen.

Es handelt sich aber nicht um deutschsprachige User!
Diese User haben einen Punkt auf der Taste im numerischen Block und leider kein Komma wie z.B. deutsche Tastaturen. Der Sinn ist nun das sie diese Taste (wegen der schnelleren Eingabe) in dezimal-Feldern nutzen können. Ich kann denen doch nicht sagen kauft euch eine deutsche Tastatur...:roll:

[DeddyH]

Was Andreas meint: die Tastatur wird ja vermutlich auch zur eingestellten Windows-Sprache passen. Von daher wäre es Quatsch, dem User landesspezifische Einstellungen aufzudrängen. Wer eine englische Tastatur verwendet, benutzt ja wohl (zumindest ist davon auszugehen) auch ein englisches Windows, japanische Tastatur lässt auf japanisches Windows und klingonische Tastatur auf klingonisches Windows schließen :mrgreen:. Das soll heißen: eigentlich sollte das in den meisten Fällen schon von sich aus funktionieren.

[Luckie]

Zitat:

Zitat von DeddyH (Beitrag 1166825)

klingonische Tastatur auf klingonisches Windows schließen

Also Windows in der original Sprache?

[DeddyH]

Jepp :D

[himitsu]

Wenn ich ein englisches Sprachschema im Windows ausgewählt ab und passend dazu ein englisches Tastaturlayout, dann ist das dezimaltrennzeichen ein Punkt und passend dazu ist im Ziffernblock auch ein Punkt vorhanden.

Stelle ich mir das Windows auf Deutsch um und passend datu auch das Tastaturlayout, dann ist das Dezimaltrennzeichen ein Komma und auch im Ziffernblock ist ein Komma.



Wieso willst du denn unbedingt ein Komma dort haben?
Es ist vollkommen egal was dort ist, solange das Programm auch richtig darauf reagiert
und als Dezimaltrenner den verwendet, welcher im System eingestellt wurde.

Er heißt ja nicht umsonst DecimalSeparator. (im Deutschen ein Dezimalkomma und Englischen ein Dezimalpunkt)

Das Dezimaltrennzeichen im Ziffernblock hat auch absichtlich einen anderen Tastencode, als das Komma links auf unserer deutschen Tastatur,
damit Windows diese Taste passend zur aktuellen Spracheinstellung mappen kann.

[Cogito]

Der Kunde möchte das so haben und, wie meist in solchen Fällen, mit der Anmerkung, das sie das in Vorgänger-Programmen auch so machen konnten. Ich erspare mir an dieser Stelle eine Diskussion mit Kunden über die Sinnhaftigkeit.:)
Mit der Prozedur "SetDecimalSeparator" hier aus diesem Thread wurde ja bereits das Dezimaltrennzeichen als Komma festgelegt und wenn ich das bisherige richtig verstanden habe wäre doch das einzige, was jetzt noch nötig wäre, die Kommataste im Num-Block IMMER als Komma zu interpretieren, jedenfalls für die Dauer der Laufzeit meines Programms. Falls das so stimmt, hat hier jemand eine Idee wie das zu bewerkstelligen ist?

[ASM]

Zitat:

Zitat von Cogito (Beitrag 1166897)

.... hat hier jemand eine Idee wie das zu bewerkstelligen ist?

Die windowsinterne Umsetzung des virtuellen Tastencodes (VK_SEPARATOR) der "Kommataste" auf dem Nummernblock wird durch die Ausführung der Funktion SetDecimalSeparator() nicht beeinflusst, bleibt also konstant wie vom System vorgegeben.

Wenn man also das Dezimalzeichen - aus welchem Grund auch immer - mittels SetDecimalSeparator() ändert und folglich zweckmäßigerweise die entsprechende Änderung auch durch den Druck der "Kommataste" des Nummernblocks gewährleisten will, kann man das nur durch Abfangen der geeigneten Message ermöglichen. Dies bezieht sich dann auf die gesamte Application, unabhängig von den verwendeten Komponenten zur Eingabe.

Code:

  {...}
  private
    { Private-Deklarationen }
    procedure AppOnMessage(var Msg: TMsg; var Handled: Boolean);
  {...}
  
procedure TForm1.AppOnMessage(var Msg: TMsg; var Handled: Boolean);
begin
  case Msg.Message of
    WM_KEYDOWN,
    WM_KEYUP:
      if (Msg.wparam = VK_DECIMAL) and (Odd(GetKeyState(VK_NUMLOCK))) then
      begin
        Msg.wparam := 190; // für Punkt
        // oder Msg.wparam := 188; // für Komma
        Msg.lparam := MakeLParam(LoWord(msg.lparam), (HiWord(Msg.lparam) and $FE00) + MapVirtualKey(Msg.wparam, 0));
      end;
  end;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
 Application.OnMessage := AppOnMessage;
end;

[Cogito]

Zitat:

Zitat von ASM (Beitrag 1166939)

Zitat:

Zitat von Cogito (Beitrag 1166897)

.... hat hier jemand eine Idee wie das zu bewerkstelligen ist?

Die windowsinterne Umsetzung des virtuellen Tastencodes (VK_SEPARATOR) der "Kommataste" auf dem Nummernblock wird durch die Ausführung der Funktion SetDecimalSeparator() nicht beeinflusst, bleibt also konstant wie vom System vorgegeben.

Wenn man also das Dezimalzeichen - aus welchem Grund auch immer - mittels SetDecimalSeparator() ändert und folglich zweckmäßigerweise die entsprechende Änderung auch durch den Druck der "Kommataste" des Nummernblocks gewährleisten will, kann man das nur durch Abfangen der geeigneten Message ermöglichen. Dies bezieht sich dann auf die gesamte Application, unabhängig von den verwendeten Komponenten zur Eingabe.

Code:

  {...}
  private
    { Private-Deklarationen }
    procedure AppOnMessage(var Msg: TMsg; var Handled: Boolean);
  {...}
  
procedure TForm1.AppOnMessage(var Msg: TMsg; var Handled: Boolean);
begin
  case Msg.Message of
    WM_KEYDOWN,
    WM_KEYUP:
      if (Msg.wparam = VK_DECIMAL) and (Odd(GetKeyState(VK_NUMLOCK))) then
      begin
        Msg.wparam := 190; // für Punkt
        // oder Msg.wparam := 188; // für Komma
        Msg.lparam := MakeLParam(LoWord(msg.lparam), (HiWord(Msg.lparam) and $FE00) + MapVirtualKey(Msg.wparam, 0));
      end;
  end;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
 Application.OnMessage := AppOnMessage;
end;

Nee sorry, die Routine scheint nicht zu funktionieren bzw. zeigt keinerlei verändertes Verhalten.
Vielleicht wäre es einfacher in meiner Applikation den Punkt als Dezimalseparator zu definieren? Dann bräuchte ich nichts am System zu verändern. Weiß jemand ob das funktionieren kann, ich meine, global für die Anwendung den Punkt als Dezimaltrenner zuzulassen?

[himitsu]

DecimalSeparator und ThousandSeparator :?:

[Cogito]

Ich hab die Lösung gefunden, es ist so simpel: Es gibt die globale Variable SysUtils.DecimalSeparator die dafür verantwortlich ist, wie Delphi das Dezimaltrennzeichen interpretiert. Das hat also gar nichts mit den regionalen Einstellungen des Systems oder sonstwelchen Einstellungen zu tun wie es scheint. Vielen Dank allen hier!

[DeddyH]

Achwas :mrgreen:

[Cogito]

Mist, doch noch nicht (ganz) gelöst. Der Kunde hat sich darauf comitted, als Dezimaltrennzeichen immer ein Komma zu verwenden. Jedoch gibt es unterschiedliche Tastaturen und alle diejenigen, die das Programm nutzen, möchten die Kommataste auf dem numerischen Block der Tastatur benutzen. Das Problem ist nun, das einige dort kein Komma haben, ich aber auch nicht an den Systemeinstellungen rumfummeln möchte, weil das eventuell wieder Einfluss darauf haben könnte, das andere Programme dann nicht mehr richtig funktionieren. Gibt es also eine Möglichkeit, das Dezimaltrennzeichen immer auf Komma zu stellen (Ja: Decimalseparator := ',') und die Taste im Num-Block IMMER als ein Komma zu interpretieren?