Wie wird i18N eingebunden

[wp_xyz]

OK, jetzt verstehe ich's. Ist aber trotzdem kein Bug von Windows, sondern eher ein Problem der Programmorganisation.

Nochmals: Schau dir das genannte Demo-Programm an. Hier sind alle übersetzten Formulare von einem gemeinsamen Vorfahren abgeleitet, "TLocalizedForm", mit der die Sprachumschaltung vereinfacht wird. Die entsprechende Unit ist eigenständig, du kannst sie dir ins Projektverzeichnis kopieren. Um deine Formulare davon abzuleiten, schreibst du in der Deklaration nicht "class(TForm)", sondern "class(TLocalizedForm)"; zusätzlich musst du noch die lfm-Datei öffnen und das erste Wort "object" gegen "inherited" austauschen. (Oder verwende sinngemäß die Komponente, die jemand im englischen Forum veröffentlicht hat: http://forum.lazarus.freepascal.org/ind ... 56262.html).

Was soll das ganze? TLocalizedForm hat eine Methode "UpdateTranslation", die du aufrufst, um die Sprache umzuschalten. In deinem Formular überschreibst du diese Methode und liest vor "inherited" die Werte der Edit-Felder in Float-Variablen. Dann kommt "inherited", was die Sprachumschaltung inkl. Anpassung Formatsettings bewirkt. Anschließend schreibst du die Variablen als Strings wieder in die Edits, also etwa so:

Code: Alles auswählen

 
uses
  ..., LocalizedForms, ...
type
  TForm1 = class(TLocalizedForm)
    Edit1: TEdit;  // Enthält Float-Zahl
  ...
  protected
    procedure UpdateTranslation(ALang: String); override;
  ...
  end;
 
procedure TForm1.UpdateTranslation(ALang: String);
var
  x: Double;
begin
  x := StrToFloat(Edit1.Text);
  inherited;  // Hier werden u.a. die DefaultFormatSetting geändert.
  Edit1.Text := FloatToStr(x);
end;
 

[and4more]

...heißt: ich muss für jedes Float/Double-Feld dieses in die UpdateTranslation-Prozedur übertragen. Das ist nicht so ohne!

[wp_xyz]

...heißt: ich muss für jedes Float/Double-Feld dieses in die UpdateTranslation-Prozedur übertragen. Das ist nicht so ohne!

Aber nur auf den automatisch erzeugten (genauer: bereits geöffneten) Formularen, bei den dynamisch erzeugten gelten beim nächsten Aufruf ja schon die geänderten FormatSettings. Bei mir wird üblicherweise nur das Hauptformular automatisch erzeugt, und da ist der Aufwand überschaubar.

Aber ehrlich: Wie soll es denn anders gehen? Woher weiß ein TEdit, dass der Eingabetext eine Zahl ist?

Aber nimm doch stattdessen TFloatSpinEdit. Das akzeptiert in der Eingabe sowohl Punkt als auch Komma. Daher kommt es auch damit zurecht, wenn nach der Umschaltung von Deutsch auf Englisch ein Punkt in der Zahl enthalten ist, nicht mehr ein Komma. Hat allerdings das Problem, dass die SpinButtons nicht immer erwünscht sind. Vielleicht sollte man einen Patch schreiben, um sie ausblenden zu können...

[and4more]

..so habe jetzt noch mal auf die Schnelle 30 Float-Werte nach oben genanntem Schema angepasst. Allerdings hat sich an der Exception bzgl. des invalid Floats nichts geändert. Muss UpdateTranslation noch irgendwie sonst aufgerufen werden?

[wp_xyz]

Klar, "UpdateTranslation" ersetzt das "SetDefaultLang" aus deinen MenuClick-Handlern weiter oben im Thread. Sorry, da war meine Anleitung oben unvollständig.

[and4more]

...wie ich gerade bemerkt habe hat sich aber eine Sache verändert und zwar wenn die Sprache vor Eingabe der Werte umgestellt wird werden die Werte mit dem korrekten Komma bzw. Punkt angezeigt. Allerdings führt ein Umschalten bei bereits eingegebenen Werten nicht zu einer Korrektur derselben.
Und nach Ersetzen von 'SetDefaultLang' durch UpdateTranslation('de') krieg' ich bei bereits eingegebenen Werten sofort 'ne Exception und nicht erst wie vorher beim Auswerten der Felder.

[wp_xyz]

Versteh ich nicht. Ich fürchte, du musst dir die Mühe machen, aus deinem Projekt eine kleine Demo zu extrahieren, die dieses Verhalten zeigt und die ich übersetzen und testen kann. (Bitte nur lpr, lpi, pas und lfm Dateien, in einem zip gepackt, hochladen, keine exe und ppu).

[and4more]

...ja, ich werd' mal schauen wann und wie ich dazu komme mal ein Beispiel zu posten (das Programm selbst ist etwas umfangreich), bin aber leider momentan ziemlich durch andere Dinge "absorbiert", da ich die "Programmiererei" nur zum Spaß/Entspannung mache und das leider nie richtig gelernt habe (Autodidact)....

[and4more]

Sooo, jetzt hab' ich mal auf die Schnelle was Kleines erstellt, was in groben Zügen dem entspricht was ich gerade mache (funktioniert genauso wenig )

[wp_xyz]

Ok, ich sehe, da ist einiges faul, sowohl in deinem Code als auch in meinem Vorschlag mit LocalizedForms/UpdateTranslation.

Das Hauptproblem ist aber ein Hausgemachtes, nämlich dass du während der Eingabe den Dezimalpunkt gegen ein Komma austauschst. Nach der Sprachumschaltung ist aber dies nicht mehr gültig, weil die DefaultFormatSettings geändert werden (in deinem Aufruf von GetLocaleFormatSettings). Lass das GetLocaleSettings einfach weg, und das Komma bleibt gültig, und alle Probleme sollten sich in Luft auflösen. Auch UpdateTranslation und die Verwendung von LocalizedForms sind nicht mehr nötig. Für die Sprachumschaltung verwende einfach folgenden Code:

Code: Alles auswählen

 
procedure TForm1.MenIt_DEClick(Sender: TObject);  // "Englisch" analog
begin
  MenIt_DE.Checked:=TRUE;
  MenIt_EN.Checked:=FALSE;
  SetDefaultLang('de'); 
  // Nehme nicht UpdateTranslation, das passt so überhaupt nicht in deine Art von Anwendung - sorry für die Verwirrung...
end;
 

Ganz sauber ist das aber nicht. Dadurch dass die Sprache umgeschaltet werden kann, muss du damit rechnen, dass dein Benutzer auf einem englischen System startet. Dann sind die DefaultFormatSettings mit Dezimalpunkt, und es kracht wieder!

Also, wenn du meinen ehrlichen Rat willst: Lass die Finger davon, während der Eingabe Dezimalpunkt in -komma zu wandeln und bleibe bei den FormatSettings des Systems. Und unterdrücke auch keine eingegebenen Zeichen, um eine gültige Zahl zu erzwingen, das mag für dich in Ordnung sein, aber den normaler User verwirrt es extrem, wenn die eingegebenen Zeichen nicht erscheinen. Zeige stattdessen eine Fehlermeldung an.

Die "richtige" Version deines Programms wird damit natürlich komplizierter, insbesondere auch, weil du die Umschaltung der Sprache während der Eingabe erlauben willst. In der Anlage habe ich dein Programm so geändert, wie es meiner Meinung nach richtig ist und auch für mehrere Formulare formulieren sollte.

Die wesentliche Änderung ist eine neue Methode "PrepareTranslation" im LocalizedForm, die vor der Sprachumschaltung aufgerufen wird, und in der alle geöffneten Formulare Zahlenwerte aus Edit-Feldern extrahieren können, um sie in einem Formular-Feld zu speichern. Das Gegenstück ist "UpdateTranslation", das nach der Sprachumschaltung aufgerufen wird, und in dem die Formulare den gespeicherten Wert wieder ins TEdit zurückübertragen können, jetzt mit den geänderten Formateinstellungen.

[and4more]

Super, vielen Dank. Jetzt ist mir alles klar. Und außerdem klappt's auch in Deiner Version. Die Eingabekorrekturfunktion hatte ich schon vor längerer Zeit erstellt, da mir bei der Plattform übergreifenden Programmierung (Windows/Linux) aufgefallen war, dass die Kommata bzw. Dezimalpunkte unter Linux und Windows anders behandelt werden. Man könnte dies natürlich auch mit {ifdef $...} und {endif $...} lösen. Außerdem war die Funktion vorhanden, da Komma und Punkt nahe beieinander liegen und so Eingabefehler automatisch korrigiert werden.