Problem mit DevExpress Printing System Lokalisierung

[uligerhardt]

Zitat von k0ppki11ah:

Ich nutze den cxLocalizer.

Zitat von k0ppki11ah:

Ich habe mittlerweile alle Formen aus dem DevExpress Installationsordner in die Sprach-Ressourcen-DLL des Projektes eingebunden, also in die <Projektname>.ENG

Wieso beides?

Zitat von k0ppki11ah:

Aber wie Union schon erwähnt hat, will ich natürlich nicht nur das Grid übersetzen, sondern das komplette UI.

Leute, das ist doch völlig logisch.

[Furtbichler]

Wenn in der Ressourcen-DLL ein Formular nicht geladen werden kann, dann steht eben in der DLL die falsche Information drin. Die ITE ist hier nicht gerade vertrauenserweckend, zumindest ist das meine Erfahrung aus uralten Zeiten. Mittlerweile benutze ich die SiLang Komponenten, aber das gehört hier nicht hin. Damit kann man auch die DevExpress-Komponenten lokalisieren, muss aber imho die Übersetzungen selbst schreiben. Aber, wie gesagt: Gehört nicht hierhin.

Ich würde den cxLocalizer nehmen und die DevExpress-Quellen aus der DLL wieder entfernen und das Teil komplett neu erstellen. Wenn das nicht hilft, das Ressourcen-DLL-Projekt wegschmeißen (die Sprache löschen), eine neue Sprache anlegen (die gleiche natürlich ) und dann kann man imho den Pfad angeben. Wenn dort schon Dateien sind, werden diese eingebunden. Damit hatte ich damals (so um 1863) meine zerballerten Ressourcen-DLL immer wieder hinbekommen.

[k0ppki11ah]

Zitat von uligerhardt:

Zitat von k0ppki11ah:

Ich nutze den cxLocalizer.

Zitat von k0ppki11ah:

Ich habe mittlerweile alle Formen aus dem DevExpress Installationsordner in die Sprach-Ressourcen-DLL des Projektes eingebunden, also in die <Projektname>.ENG

Wieso beides?

Beides weil ich für den cxLocalizer bereits eine fertige Sprachdatei mit deutscher Übersetzung habe.
Läuft das Programm auf deutsch, aktiviere ich den cxLocalizer, läuft es auf englisch deaktiviere ich ihn, da die native Sprache der DX Komponenten ja Englisch ist.

Die Formen müssen, wie in einem Support-Topic im DevExpress Forum beschrieben, in die DLL integriert werden.

Das mit dem Rebuild der DLL hatte ich schon versucht. Bringt leider auch nichts. Der Fehler lässt sich auch einem neuen Projekt so reproduzieren.

Auch wenn es ein wenig offtopic ist: Die ITE ist in der Tat nicht wirklich vertrauenserweckend. Aber ich musste schnell weiterkommen und wollte keine kostenpflichtigen Drittkomponenten dafür einsetzen.

[Furtbichler]

Zitat von k0ppki11ah:

Aber ich musste schnell weiterkommen...

Merkst Du den Widerspruch? Egal.

Bezüglich des Support-Topics... hast Du da den Link?

Mein Tipp: Schmeiss die DevExpress-Komponenten aus der Resourcen-DLL. Ich hatte die jahrelang nicht drin und alles lief.

[k0ppki11ah]

Zitat von Furtbichler:

Zitat von k0ppki11ah:

Aber ich musste schnell weiterkommen...

Merkst Du den Widerspruch? Egal.

Ja, ist mir auch schon aufgefallen

Den genauen Link hab ich jetzt gerade leider nicht mehr gefunden.

Aber hier ist ein ähnliches Problem (allerdings C++): http://www.devexpress.com/Support/Center/p/Q293316.aspx

Wenn ich die DevExpress Formen aus der DLL entferne, funktioniert gar nichts sobald ich auf Englisch umschalte.

Es hagelt dann EResNotFound Exceptions

[Mschmidt]

Ich benutze die DevEx Componenten (alle) schon seit Jahren. Und auch bisher gabs mit der Uebersetzung via cxLocalizer keine Probleme, egal ob deutsch oder englisch. Ich wuerde empfehlen, den ganzen ressourcenkram abzubauen,eine uebersetzung mit dem DevEx Tool zu bauen, die eigenen Strings hinzuzufuegen und fertig. Das abschalten des cxlocalizer bei Verwendung der nativen Sprache ( US englisch) halte ich nicht fuer sinnvoll, da einige Zeichen ( zb. TcxGridview, options, Text fuer leere Datenmenge im Oi setzbar) dann nicht geaendert werden.
Cheers
Mathias

[k0ppki11ah]

Das Problem hat sich mittlerweile geklärt.

Eine der .dfm Dateien (dxPScxGridLnk.dfm) innerhalb der Ressourcen DLL war korrupt, bzw. wird beim ersten Einbinden in die DLL abgeändert. Das liegt aber nicht am Projekt, sondern tritt reproduzierbar auch in Testprojekten auf. Möglicherweise ein Bug der ITE.

Zitat von Mschmidt:

Das abschalten des cxlocalizer bei Verwendung der nativen Sprache ( US englisch) halte ich nicht fuer sinnvoll, da einige Zeichen ( zb. TcxGridview, options, Text fuer leere Datenmenge im Oi setzbar) dann nicht geaendert werden.

Da muss ich dir absolut Recht geben. Ich werde in die DX Sprachdatei einfach noch die englischen Strings integrieren.

Die Komplette Ressourcengeschichte abzubauen werde ich evtl. mal angehen, wenn wieder was Luft da ist.

Das verlockende daran war einfach die Tatsache, dass direkt die Breite der Komponenten usw mitangepasst werden können, falls es erforderlich wäre.

Dynamische Strings und Meldungstexte lade ich abhängig von der Spracheinstellung sowieso aus einer DB.

Vielen Dank für eure Ansätze

[Mschmidt]

Zitat von k0ppki11ah:

Das Problem hat sich mittlerweile geklärt.
Das verlockende daran war einfach die Tatsache, dass direkt die Breite der Komponenten usw mitangepasst werden können, falls es erforderlich wäre.

Noch ein Nachtrag... Mit verwendung der devex Koponente TdxLayoutControl ist die Laenge der Zeichenketten mehr oder weniger irrelevant.
Cheers