VCL Unicode, AnsiString übergeben!

[himitsu]

Zitat:

Zitat von Mavarik (Beitrag 1131291)

Delphi 6 ist doch sehr schön...

Deswegen gibt es ja auch, beim Kauf von XE/XE2, ein D2007 gratis dazu :mrgreen:

[Bernhard Geyer]

Zitat:

Zitat von mquadrat (Beitrag 1131286)

17.900???? :shock:

Ach herrje.. Alles von der Unicode-Umstellung? Jeden Tag 1000, dann biste in knapp drei Wochen durch :D

Erst mal die Warnungen bezüglich String->AnsiString abschalten und dann auf die relevanten konzentrieren.
Den Datenverlust String->AnsiString haben viel bis D2009 mehr oder minder schon immer gehabt solange man auf NT-Systemen gearbeitet hat.

[Mavarik]

@himitsu also das doppelte casten funktioniert...

Obgleich ich den Sinn nicht verstehe... Bzw. warum es dann funktioniert!

Vielleicht sollte ich nochmal den original Source nehmen und nicht alle Strings nach AnsiString konvertieren...

Das Problem ist, unsere Software geht davon aus, dass GLOBAL {$H-} gesetzt ist... Da es das ja nicht mehr gibt, habe ich innerhalb von {$H-} Blöcken aus jedem String einen Shortstring gemacht und außerhalb halt zu AnsiString.

Char's hab ich per Hand konvertiert weil zu viele VCL-Override proceduren von eine automatischen Char-AnsiChar Konvertierung betroffen waren.

War vielleicht der falsche Ansatz...

Mavarik

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1131295)

@himitsu also das doppelte casten funktioniert...

Obgleich ich den Sinn nicht verstehe... Bzw. warum es dann funktioniert!

Ist ja auch nicht wirklich ein "einfaches" Casten. Hier springt etwas die Compilermagic an und erzeugt kurzfristig einen richtigen (Unicode)String den du dann als PChar verwenden kannst.

Zitat:

Zitat von Mavarik (Beitrag 1131295)

Vielleicht sollte ich nochmal den original Source nehmen und nicht alle Strings nach AnsiString konvertieren...

Wäre vieleicht gut.

Zitat:

Zitat von Mavarik (Beitrag 1131295)

Das Problem ist, unsere Software geht davon aus, dass GLOBAL {$H-} gesetzt ist...

Autsch. Dann liegen dein Problem eher daran das man bei der 16->32-Portierung sich Zeit sparen wollte... Na ja. Irgendwann rächt sich sowas.

[Mavarik]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1131298)

Autsch. Dann liegen dein Problem eher daran das man bei der 16->32-Portierung sich Zeit sparen wollte... Na ja. Irgendwann rächt sich sowas.

Nein ich denke das liegt an der 8 Bit-> 32 Bit Portierung! :roll:

Der Sourceode kommt in vielen Teilen noch von Turbo-Pascal!

Mavarik

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1131300)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1131298)

Autsch. Dann liegen dein Problem eher daran das man bei der 16->32-Portierung sich Zeit sparen wollte... Na ja. Irgendwann rächt sich sowas.

Nein ich denke das liegt an der 8 Bit-> 32 Bit Portierung! :roll:

Der Sourceode kommt in vielen Teilen noch von Turbo-Pascal!

Lange Strings kann Delphi erst mit der 32-Bit Version Delphi2. Unter Delphi1 gab es nur kurze Strings.
Musste damas auch etwas umstellen als ich für die Serielle Kommunikation Strings mißbraucht hatte.
Als ich dann das nach D1 rückportieren musste, hatte ich hier Umstellungsaufwand.

[Mavarik]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1131304)

Als ich dann das nach D1 rückportieren musste, hatte ich hier Umstellungsaufwand.

D1 haben wir ausgelassen..

Und denn an den Stellen wo wir es brauchen, explizit {H+} Blöcke eingefügt!

[derMischka]

Hallo Maverik,

wenn Du auch noch mit Delphi Versionen <= 7 arbeitest:

http://www.delphipraxis.net/175267-d...ig-machen.html

hab es bis jetzt nur mit Delphi 7 getestet.

der Mischka