dxGetText: Exceptions zu lokalisieren war ein Fehler, oder?

[Uwe Raabe]

Wie wird die Exception denn angezeigt? Benutzt du das interne Verfahren, sowas wie madExcept oder was eigenes?

[Der schöne Günther]

Nein, das ist einfach nur ein selbst gebautes VCL-Fenster mit einem traurigen Smiley, dem Exception-Text und einem Button für eine Diagnose-Zip-Datei auf einen Stick zu speichern.

Warum, was würde das ändern?

Aber so wie es aussieht habe ich schon eine Lösung:

Ein Ressourcenstring ist erst einmal ein TResStringRec und kein String!

Ich habe der Exception-Oberklasse also einen neunen Konstruktor hinzugefügt:

Delphi-Quellcode:

   EDeviceException = class(Exception)
      public var
         resStr: PResStringRec;
      public
         constructor Create(const resStr: PResStringRec); {$If Defined(Test)}overload;{$Endif}
   end;

constructor EDeviceException.Create(const resStr: PResStringRec);
var
   translated: String;
begin
   self.resStr := resStr;

   translated := System.LoadResString(resStr);
   inherited Create(translated);
end

.

Heißt: Es geht weiter wie bislang. Aber das Exception-Objekt hat jetzt noch einen Verweis auf den originalen Ressourcen-String. Vorausgesetzt ich sage fortan nicht mehr
raise EDeviceException(someText) sondern
raise EDeviceException(@someText) Beim Loggen der Exception kann ich mich dann an diesem PResStringRec wieder zu einem englischen oder deutschen Text hangeln.

Jetzt darf ich nur den CreateFmt-Konstruktor nicht vergessen und dann sieht das schon sehr gut aus

[Uwe Raabe]

Wären nicht diese Konstruktornamen besser geeignet?

CreateRes
CreateResFmt
CreateResFmtHelp

[Der schöne Günther]

Wie konnte ich das übersehen!

Vielen Dank, das nimmt ja ein echtes Happy End