Regionale Einstellungen

[himitsu]

Wieso verwendet man hier auch LPSTR?

Zitat:

LPSTR = PAnsiChar;

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

Oder man nimmt einfach PChar.


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 von Cogito:

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 von shmia:

Zitat von Cogito:

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...

[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 . Das soll heißen: eigentlich sollte das in den meisten Fällen schon von sich aus funktionieren.

[Luckie]

Zitat von DeddyH:

klingonische Tastatur auf klingonisches Windows schließen

Also Windows in der original Sprache?

[DeddyH]

Jepp

[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 von Cogito:

.... 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;