Fehlerhafte Resourcestrings Verwaltung

[BastiFantasti]

Hallo zusammen,

ich entwickle aktuell eine Anwendung (bzw. hier eine DLL), in der ich Statusmeldungen als Resourcestrings definiert habe.
Bis gestern konnte ich die Anwendung noch kompilieren, ausführen und debuggen.

Heute morgen wollte ich den leicht erweiterten Code debuggen und bin dabei auf ein Problem gestoßen.

Delphi verwechselt aus mir nicht nachvollziehbaren Gründen die Resourcestrings.

In Zeile 119 (1) erfolgt die Formatierung des Resourcestrings mit

Delphi-Quellcode:

Format(S_ServerMaschinenEingelesen,[ErpRestClient.GetMachineCount])

das GetMachineCount Property ist vom Typ Integer, der Formatierungsstring wie oben angegeben ist:

Delphi-Quellcode:

S_ServerMaschinenEingelesen = '(%d) Maschinen für Arbeitsplatz eingelesen';

Beim Formatieren des Integers in den Resourcestring kommt nun während der Ausführung die angezeigte Fehlermeldung (2)

Delphi verwechselt hier scheinbar die beiden resourcestrings "S_ServerMaschinenEingelesen" mit "S_MaschineOK".

Screenshot ist angefügt...

Kennt jemand das Problem und weiß ggf Abhilfe?

Viele Grüße
Bastian

[BastiFantasti]

Problem hat sich erledigt.

Das Problem hängt mit unserem Internationalisierungstoolkit zusammen.
Scheinbar hat sich die Struktur der Sprachdateien durch meine Codeerweiterung verändert.

Wie genau das Tool intern arbeitet weiß ich nicht. Aber scheinbar hat er in der Sprachdatei an dem neuen Speicherbereich den alten Text hinterlegt gehabt.
Ich hab die Sprachdateien nun in das Ausgabe/Debug Verzeichnis kopiert und es klappt wieder :thumb:

[TiGü]

Bei Änderungen an der EXE/DLL muss die dazugehörige Resourcen-DLL (*.DE, *.EN, usw.) immer mit aktualisiert werden.

[BastiFantasti]

ja, die hatte ich vergessen ins Ausgabeverzeichnis zu kopieren :oops:

[himitsu]

Ressourcen falsch/nicht neu kompiliert?
Gibt es irgendwo alte SprachDLLs? (weißt ja, wie bei vcl280.bpl und vcl280.de)

Und RessourceStrings besser so benutzen

Delphi-Quellcode:

LoadResString(@S_ServerMaschinenEingelesen)

anstatt nur

Delphi-Quellcode:

S_ServerMaschinenEingelesen

,
damit sie auch wirklich immer aus der Ressource kommen und nicht eventuell nur als stinknormale Konstante einkompiliert werden.
(so, wie man es z.B. bei Exception.CreateRes und CreateResFmt überall sieht)

[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:

Zitat von BastiFantasti (Beitrag 1513612)

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 - 8-)

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

[Uwe Raabe]

Zitat:

Zitat von BastiFantasti (Beitrag 1513763)

was für Tools hast du dir für den Localizer gebastelt - 8-)

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.

Genau das erfüllt auch mein Tool LocalizerConvert, das LNG in XML umwandelt und umgekehrt. Die bordeigene XML-Konvertierung deckt leider nicht 100% der Daten ab.

Dann gibt es noch LocalizerMerge, mit dem ich mehrere Language Files vereinen kann. Das ist in meinem Fall hilfreich, da ich mehrere Projekte habe die viele Units gemeinsam nutzen. So kann ich die Übersetzungen in der Merge-Datei pflegen und mit einem weiteren Tool LocalizerTranslate die Übersetzungen später in die jeweiligen LNG-Dateien der einzelnen Projekte einpflegen, wobei das Translate-Tool auch PO-Dateien für die Übersetzung verwenden kann.

[BastiFantasti]

Zitat:

Zitat von Uwe Raabe (Beitrag 1513774)

Zitat:

Zitat von BastiFantasti (Beitrag 1513763)

was für Tools hast du dir für den Localizer gebastelt - 8-)

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.

Genau das erfüllt auch mein Tool LocalizerConvert, das LNG in XML umwandelt und umgekehrt. Die bordeigene XML-Konvertierung deckt leider nicht 100% der Daten ab.

Dann gibt es noch LocalizerMerge, mit dem ich mehrere Language Files vereinen kann. Das ist in meinem Fall hilfreich, da ich mehrere Projekte habe die viele Units gemeinsam nutzen. So kann ich die Übersetzungen in der Merge-Datei pflegen und mit einem weiteren Tool LocalizerTranslate die Übersetzungen später in die jeweiligen LNG-Dateien der einzelnen Projekte einpflegen, wobei das Translate-Tool auch PO-Dateien für die Übersetzung verwenden kann.

Welchen Vorteil hat die Konvertierung in XML? Wir exportieren die Strings immer in txt Dateien.
Diesen Export kann man über eine Konfigdatei beeinflussen, was alles mit exportiert werden soll - hat bis jetzt eigentlich immer gut funktioniert.

Das mit dem Verwalten der unterschiedlichen Versionen der Sprachdateien für Anwendungen mit unterschiedlichem Kontext klingt interessant.
Dies trifft uns auch, da wir eine Standardanwendung in unterschiedlichen Varianten erstellen und die Sprachdateien bzw. die versionsspezifischen Units separat übersetzen sollten.

Hast du das auf Basis der XML Dateien gelöst oder gibt es da irgendwelche Kniffe innerhalb dem Localizer.

[himitsu]

XML/JSON/... bestimmt einfach nur als ein menschenlesbares, aber dennoch "einfacher" maschienenlesbarere Format.

[Uwe Raabe]

Zitat:

Zitat von BastiFantasti (Beitrag 1513870)

Welchen Vorteil hat die Konvertierung in XML? Wir exportieren die Strings immer in txt Dateien.

Ich finde XML eigentlich ein adäquates Format für die Informationen, die dort untergebracht werden:

XML-Code:

      <component name="FrCfgEditAggToolPlace1.LbOffset" attr="0">
        <prop name="Caption" attr="32" proptype="ptString">
          <id>407</id>
          <version>1</version>
          <modified>1899-12-30</modified>
          <value>&amp;Korrektur ( X/ Y/ Z ):</value>
        </prop>
      </component>

Insbesondere erlaubt mir das eine vollständige Umwandlung in beide Richtungen. Eine Konvertierung LNG -> XML -> LNG erzeugt exakt die gleiche LNG-Datei wie vorher. Die ganzen Informationen in einem anderen Text-Format unterzubringen hätte zunächst die Definition eines entsprechenden Formates bedurft. Dann kann ich auch gleich ein etabliertes Format nehmen.

Zitat:

Zitat von BastiFantasti (Beitrag 1513870)

Hast du das auf Basis der XML Dateien gelöst oder gibt es da irgendwelche Kniffe innerhalb dem Localizer.

Den Localizer-Code habe ich nur an einer Stelle anpassen müssen, bei der ich im Merger Einfluss auf die LoadOptions beim Öffnen eines TLangFileProject brauche (loSyncByName, loRepair).

Alle Manipulationen arbeiten mit den Localizer-Klassen. Daher müssen die Tools auch immer mit der aktuellen Localizer-Version compiliert werden. Das gilt insbesondere auch für das LocRefresh vom Localizer selbst, weshalb das auch im Build-Prozess jedesmal neu erzeugt wird.