Multilingual mit DLLs u. Unicode - so richtig?

[TheMiller]

Danke für deine Hilfe. Das mit den globalen Vars und dem nicht verwendeten s kam vom Testen. Das mit dem WideString etc ist mir dann auch aufgefallen und an UnicodeString habe ich garnicht gedacht....

Also verstehe ich dich richtig, dass ich die o.g. Unit einbinden soll, und dann einfach die Strings übergeben soll, WENN ich schon die Version mit der DLL durchziehen möchte?

Ich würde - warum auch immer, ich weiß es selbst nicht - gerne bei den DLLs bleiben. Finde ich irgendwie übersichtlicher und mit Ressourcen habe ich noch nicht viel gearbeitet.

Was spricht gegen DLLs?

Danke!

[himitsu]

"Sollen" nicht unbedingt, aber es würde bestimmt Einiges vereinfachen.

- du kannst direkt UnicodeString als parameter angeben (entspricht seit 2009 ja dem string, also keinerlei Konvertierungen im Betrieb)
- und du kannst die Vorzüge der Strings nutzen ... keine "unsicheren" Speicheropertationen und PWideChar-hinundherkopiere

Delphi-Quellcode:

  TLang = function (str: LongInt): UnicodeString;
  TComp = function (const comp: UnicodeString): UnicodeString;

UnicodeString anstatt String, da man solche Interfaces besser mit statischen Typen deklariert ... nicht daß sich das Interface urplötzlich verändert, wenn man auf ein anderes Delphi umsteigt oder für ein anderes System kompiliert (32 Bit und 64 Bit, ANSI und Unicode, ...)


Würde am Ende auch ein bissl der Performance zu Gute kommen, wenn da öfters mal was ausgelesen würde.

Bzw. die UnicodeStrings verbrauchen keinerlei Arbeitsspeicher, da sie, über einen Spezialfall der Referenzzählung als Konstante im "Speicher" liegen.
Die Stringdaten verbleiben in der Datasektion (oder wo auch immer die liegen) und es werden immer nur Zeiger darauf weitergegeben.
(solange man den String nicht manipuliert, ala Copy , Delete oder + )

[TheMiller]

Hi!

Super Erklärung - hat auch alles soweit super funktioniert. Ist ja wirklich so, als würde man Strings zwischen zwei Formularen austauschen.

Aber eine Frage habe ich noch... Habe ich jetzt noch die Möglichkeit, nach MemoryLeaks über FastMM zu suchen? Eigentlich ja nicht, weil sich FastMM ja nicht mehr laden kann, weil ja schon ein anderer MemoryManager installiert ist. Hast du da zufälligerweise auch noch einen Tipp für mich?

Vielen Dank

[TheMiller]

Moin!

Habe jetzt mal soweit alles fertig. Würde es euch aber gerne nochmal zeigen. Zum einen, dass ihr mir noch Vorschläge geben könnt und zum anderen hilft es vielleicht ja jemand anderen noch.

Es ist jetzt so, dass beim Sprachenwechsel alle gewünschten Objekttypen automatisch ersetzt werden. D.h., ich trage in die Änderungsliste den Typ TButton ein und alle Buttons auf der Form werden übersetzt. Vielleicht ist das auch zu kompliziert und ihr habt noch andere Ideen.

Es würde mich freuen, wenn ich nochmal drüberschaut. Es ist nicht viel Quelltext, wollte aber dennoch nicht alles in den Beitrag posten - sonst muss man wieder Kilometer runterscrollen.

Danke

[himitsu]

Das Ding nutzt ja den FastMM, welcher im Delphi integriert ist ... du mußt nur noch dort die Speicherprüfung aktivieren, wo er geladen ist.


Je nach dem, was zuerst geladen wird, da wird er verwendet.
- statisch geladene DLLs/BPLs werden vo der EXE geladen
- dynamisch (manuell ... LoadLibrary) geladene DLLs/BPLs werden nach der aufrufenden EXE/DLL geladen.


("nochmal drüberschaut" ... nach Feierabend dann)

[TheMiller]

Ok, vielen Dank für deine Hilfe.

[himitsu]

Bitte.


Dieses Prüfenbeirunterfahrenfläg kannst du aber notfalls auch einfach überall setzen.
irgendeiner wird es dann schon machen.