Fehlerhafte Resourcestrings Verwaltung

[BastiFantasti]

Ja es lag an den alten Sprach DLLs...

im Zusammenhang mit welchem Lokalisierungsansatz werden die von dir beschriebenen Funktionen LoadResString / Exception.CreateRes ... verwendet?

[himitsu]

z.B. einige GNUGetText-Sachen und Andere hooken LoadResString, um auch zur Laufzeit eine andere Sprache zu laden
und auch DevExpress hängt sich da rein.

[Uwe Raabe]

Die Resourcestrings werden vom Compiler über Zahlen angesprochen, die sich leider recht häufig ändern. Das entsprechende Mapping wird in die .DRC geschrieben. Diese wird in der Regel von den Lokalisierungstools ausgewertet um die Verbindung zwischen dem Namen des ResourceString im Code mit der Nummer in der erzeugten Resource herzustellen. Wenn man dann nicht die passenden Resourcen zur erzeugten EXE hat, kommt das System natürlich durcheinander.

[himitsu]

Jupp, es wird einfach blind hochgezählt.
"Diese" RessourceStrings sind auch in Gruppen (Tabellen) aufgeteilt, in denen es technisch keine Leerstellen gibt.
Du brauchst nichtmal an deinem Code was ändern ... einfach nur eine neue Delphi-Version oder Units in einer anderen Reihenfolge kompiliert/gelinkt und schon sind die Nummern anders.

Alternativ könnte man auch jeden einzelnen String als eigenständige Ressource einbinden, mit fester Nummer/ID oder gar mit Namen.
Für größere mehrzeilige Texte angebracht und auch nutzbar, aber da muß dann jeder einzelne String/Text/Binärdaten/... z.B. mit TRessourceStream geladen werden.

[BastiFantasti]

Das heißt das ist kein unsägliches Verhalten von dem Localizer, sonder das ist eine Delphi Design Frage, bzw. allgemeine Strategie wie Delphi die Strings verwaltet?

[Uwe Raabe]

Zitat von BastiFantasti:

Das heißt das ist kein unsägliches Verhalten von dem Localizer, sonder das ist eine Delphi Design Frage, bzw. allgemeine Strategie wie Delphi die Strings verwaltet?

Eigentlich ist das die Vorgabe für Strings in Windows-Resourcen, die einen 16 Bit Integer als ID erfordern. Netterweise kümmert sich Delphi um das Mapping, damit wir nicht im Programm mit diesen IDs rumhantieren müssen. Damit es da möglichst keine Kollisionen gibt, zählt Delphi die IDs von 65535 an rückwärts. Trotzdem kracht es da bei vielen Resource-Strings und manchen Fremdbibliotheken, die intern einen höheren Bereich verwenden (anstatt das Delphi machen zu lassen).

Ich habe mir für Localizer eine Reihe von Tools für die Arbeit mit den LNG-Dateien gebaut, die einige Dinge leichter machen. Der Build-Server stellt auch immer die passenden LNG-Dateien für eine neue EXE bereit. Beim Debuggen muss man sich halt selbst darum kümmern.

[himitsu]

Nein, das ist grundsätzlich erstmal Windows-PE-Zeugs,
wie das dort "diese" Strings verwaltet.

Und ResourceString ist nur die vereinfachte Pascal-Implementierug, aus dem Quellcode raus.

https://learn.microsoft.com/en-us/wi...table-resource

[BastiFantasti]

@himitsu:

alles klar. Dann muss man sich da einfach dran gewöhnen und dran halten

@Uwe Raabe:
das klingt interessant - was für Tools hast du dir für den Localizer gebastelt -

Ich hab mir den Localizer nur dahingehend "automatisiert", dass er vor dem Commit des Codes die LNG Dateien in Textdateien extrahiert für die Versionierung.

Viele Grüße
Bastian