mehrsprachige Resourcen nutzen

[himitsu]

@Remko: nja, etwas davon nutze ich ja schon ^^,
aber du hast mich auf eine Idee gebracht.

wenn ich's schaff SetThreadLocale/GetThreadLocale (oder sowas) auf auf die ganze Anwendung auszudehnen (wär schon gut wenn die gesamte Anwendung in einer Sprache angezeigt würde und nicht für jeden Thread einzeln ... aber mal sehn, vielleicht ist der Name ja nur Verwirrung),

dann könnte ich frGUILang abschaffen.
(schließlich wird als Zweites und dann Erstes die ThreadLocale abgefragt)


hab inzwischen noch etwas rumgetestet und eigentlich kaum noch was geändert,
aber die demo wurde nochmals "drastisch" überarbeitet ... jetzt sollte das mit der Sprachauswahl besser zu erkennen sein.




Aber MUI scheint doch nur für installierte Sprachen nutzbar zu sein?
Wenn ja, dann wäre es nachteilig ... weil, so wie wir es bisher auslesen, werden alle Sprachen (wofür eine Resource vorhanden ist) unterstützt.



zum Bild/zur Demo:
Parameter und Globale (frGUILang) auf 0, also ohne Sprachangabe (LANG_NEUTRAL)
und schon wurd das vorhandene automatisch ausgewählt.
in EXE ist nur eine englische Resource enthalten und daher wählt "Button3" nur das Englische
in den DLLs ist auch meine Sprache (hab 'nen deutsches Windows) und daher kommt bei Button4 Deutsch raus.

[Dezipaitor]

Jetzt fehlt nur noch, Anwendungen die die Systemsprache verwenden auch in einer anderen Sprache starten lassen zu können, indem man die entsprechenden Funktionen hookt.

[Dezipaitor]

Das oben kannste alles vergessen!

Delphi kann mit Resourcen, die dieselbe ID besitzen (trotz unterschiedlicher Sprachen) nicht umgehen. Jedes mal, wenn man kompiliert, erzeugt eine solche mehrsprachige Resourcendatei ein Speicherleck. Nach der x-ten Kompilation hat man dann ein Out Of Memory Fehler in der Delphi IDE. Das ist bestätigt für D5, D7 und 2007. 2006 scheint zu funkzen.

Siehe http://qc.codegear.com/wc/qcmain.aspx?d=57701

Mich wundert es, dass dieser Bug so lange unbekannt blieb.

[himitsu]

Zitat:

Mich wundert es, dass dieser Bug so lange unbekannt blieb.

hmmm, nja, es funktioniert ja ... also das Kompilat ist ja in Ordnung ... Problem hat da wohl nur der Linker.
und mit genug freiem Speicher dauert es ja 'ne Weile bis zum Out of Memory ... jetzt noch selten Kompilieren und er taucht sehr spät auf, also garnicht.

hab's grad selber ausprobiert ... bei meinem D7 sind es jedesmal nur 3-9 MB mehr, also nicht so tragisch und Delphi neu gestartet ist der speicher ja wieder frei (D7 ist beim Neustarten ja noch recht fix).

und in der erstellten EXE scheint es ja keine Probleme zu geben, also seh ich dahingehend keine Probleme, die es mich vergessen lassen sollten?

[Dezipaitor]

mit der JWSCL.res ??? nur 3-4mb ?
Das kann nicht sein.

[himitsu]

Nein, mit meiner Funktion kommen nur 3-4 MB bei jeder Kompilierung dazu.

Also mich stört das wirklich nicht,
vorallem da dieses Speicherleck ja nur Compiler ist und anscheinend nicht im Programm (der erstellten EXE).

[Dezipaitor]

Naja bei Miniprogrammen ist das kein Problem.

Der einzige Ausweg wäre hier nur noch eine Resourcen DLL. Diese muss man nicht immer mitkompilieren.

[himitsu]

Resourcen-DLLs hätten wieder einen Nachteil ... das Programm, wo ich es derzeit nutze, besteht nur aus einer einzigen EXE.


nja, bei mir ist es ja aktuell kein "großes" Leck
und im Notfall könnte man doch einfach andere Sprachen weglassen, solange man am Programm arbaitet/programmiert (Compilerswitches?)