Delphi 6 -> XE(4) wie mit char/pchar umgehen

[stalkingwolf]

Morgen zusammen.

Wir portieren unsere Software ( + externe Komponenten usw ) von Delphi 6 nach XE4 und das Hauptproblem machen mir die alten char/pchar Variablen.
Nicht nur in unserer Software sondern auch in Komponenten/Units von Drittanbietern die teilweise nicht mehr weiterentwickelt werden.

Die Holzhammer Methode mit

Code:

type char = ansichar;
type pchar = pansichar;

ist zwar ganz nett, aber bringt auch wieder Probleme an anderen stellen.

Code:

var a :char;
begin
a := mystring[1]; // Fehler beim compilieren

oder Api Befehle die widechar haben möchten.

Wie löst man das ganze am besten oder muss man in den sauren Apfel beißen?
Unser Quellcode ist nicht gerade klein und würde das schon gerne effizient angehen.

LG
Sven

[Mavarik]

Zitat:

Zitat von stalkingwolf (Beitrag 1328587)

oder Api Befehle die widechar haben möchten.

Darauf bin ich auch mal reingefallen... Dadurch macht die Holzhammer-Methode leider keinen Sinn...

Ob die Strings jetzt 1 oder 2 Byte haben, ist eigentlich egal. Ein Converter muss nur an die Stellen, wo Strings direkt in einen Stream oder per Record auf die Platte geschrieben werden.

[Vereinfacht gesagt]

Mavarik

[stalkingwolf]

Ich bin gerade dabei die XMLLib anzupassen ( die läuft ) und nun an Tcipher ( läuft noch nicht ).
Das ganze ist schon ziemlich aufwendig.

[Bernhard Geyer]

Zitat:

Zitat von stalkingwolf (Beitrag 1328587)

Wie löst man das ganze am besten oder muss man in den sauren Apfel beißen?

Darum kommst du nicht herum.

Zitat:

Zitat von stalkingwolf (Beitrag 1328587)

Unser Quellcode ist nicht gerade klein und würde das schon gerne effizient angehen.

Also wir haben (vor bald 15 Jahren) angefangen indem wir einen neuen String-Typ definiert hatten und überall diesen statt String eingesetzt haben.
Bei jedem Einsetzen konnten wir davon ausgehen das es noch unter D6 ohne Probleme funktionierte und wir somit immer noch lieferfähig waren.
Beim ersetzen am besten gleich die Anwendung auf Code-Dupletten prüfen (sammelt sich so einiges mit der Zeit an) und zusammenfasse.
Strukturen die Ansi-Strings benötigen in Klassen verpacken und diese Abhängikeit mit Getter/Setter verstecken.

[freimatz]

Es muss ja nicht immer gleich ein Apple sein :wink:
Sauer ist er trotzdem und rum kommen tust du auch nicht.
Damals habe ich tatsächlich erst mal alles ansifiziert, dazu in alle units bei uses zuerst eine u_D2009 eingefügt, die die typdefinition enthielt.
Bei den Windows-Api Aufrufen habe ich erst mal alle zu der A Variante geändert.
Mir waren damals die Generics wichtig und Unicode erstmal egal.
Erst später habe ich die Strings dann zug um zug umgestellt.

[stalkingwolf]

Der Code muss übrigens nicht mehr unter D6 laufen.
Wir stellen komplett um auf XE4.

Ich verzweifle gerade an DECCipher.
Einer unsere alten Kollegen hat die benutzt um unsere Lizenzdatei mit MIME64 zu codieren.

Aktuell arbeite ich mich durch ein kleines Programm durch und ändere unsere ganzen Units ab, so dass sie a) übersetzbar sind und dann b) lauffähig.
Hölzchen-Stöckchen Methode

Danke für die Antworten. Die types habe ich heute morgen schon entfernt und selber Hand angelegt.

[hoika]

Hallo,

willkommen im Club ...

Ich verzweifle gerade an DECCipher.
Einer unsere alten Kollegen hat die benutzt um unsere Lizenzdatei mit MIME64 zu codieren

Das geht auch mit den Indy-Komponenten.


Heiko

[stalkingwolf]

Ich hab es hinbekommen gestern. Alles in DECCipher auf ansistring/ansichar geändert und auch die Übergabe auf Ansistring gecastet.
Kann es nun einwandfrei benutzen.