VCL Unicode, AnsiString übergeben!

[Mavarik]

Hallo Zusammen...

Nachdem ich jetzt meine Software auf XE2 umgestellt habe, habe ich an vielen Stellen chinesische Schriftzeichen....

Das Problem liegt warscheinlich hier:

Delphi-Quellcode:

procedure TCustomMaskEditOwn.SetEditText(const Value: Ansistring);
begin
  if GetEditText <> Value then
  begin
    SetTextBuf(PChar(Value)); // <---
    CheckCursor;
  end;
end;

Wie unterdrücke ich beim Typcasten eine interpreation der Zeichen im String?
SetTextBuff erwartet nunmal eine PChar!

Mavarik :coder:

[Bernhard Geyer]

Ändere deine Methodensignatur auf String.

[DeddyH]

PChar = PAnsiChar bei Delphi < 2009, danach PWideChar. Wenn Du also einen AnsiString verwendest muss es dann wohl explizit PAnsiChar sein.

[edit] Oder besser so wie Bernhard sagt, auf jeden Fall nicht die Typen mischen. [/edit]

[Mavarik]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1131277)

Ändere deine Methodensignatur auf String.

Damit verlagere ich das Problem doch nur eine Stufe nach außen, oder?

Ich habe intern doch "nur" AnsiString.. Nur wenn ich mit der VCL "reden" will muss ich die ja an irgend einer Stelle mal von AnsiString an WideString zuweisen!

Mavarik

[himitsu]

Oder den String in eine temporäre Variable vom Type String, bzw. bei Übergabe doppelt casten.

Delphi-Quellcode:

SetTextBuf(PChar(String(Value)));

.


Oder du stellst deinen Code auf Unicode um. :stupid:



Wenn du außerhalb einen AnsiString oder einen PAnsiChar an eine String/UnicodeString-Variable, bzw. an soeinen Parameter übergibst, dann konvertiert Delphi das automatisch.

Zitat:

habe ich an vielen Stellen chinesische Schriftzeichen....

Vermutlich?
Delphi sollte dir genau sagen, daß es dort ein Problem gibt. (es müßte eine Compiler-Warnung vorhanden sein)

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1131281)

Damit verlagere ich das Problem doch nur eine Stufe nach außen, oder?

Ich habe intern doch "nur" AnsiString.. Nur wenn ich mit der VCL "reden" will muss ich die ja an irgend einer Stelle mal von AnsiString an WideString zuweisen!

Nicht ganz (Abgesehen davon das du "intern" auf Strings (=UnicodeString) umstellen solltest.
Einen AnsiString->Unicodestring "bestraft" dich der Compiler nur mit einer Compilerwarnung (Evtl. Datenverlust), aber Wandlung macht er korrekt. Bei P(Wide/Ansi)Char's kann er das nicht. Da müsstest du selbst mit Hilfsvariablen + 1-2 Codezeilen umschiffen.

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1131282)

Oder den String in eine temporäre Variable vom Type String, bzw. bei Übergabe doppelt casten.

Delphi-Quellcode:

SetTextBuf(PChar(String(Value)));

.


Oder du stellst deinen Code auf Unicode um. :stupid:



Wenn du außerhalb einen AnsiString oder einen PAnsiChar an eine String/UnicodeString-Variable, bzw. an soeinen Parameter übergibst, dann konvertiert Delphi das automatisch.

Zitat:

habe ich an vielen Stellen chinesische Schriftzeichen....

Vermutlich?
Delphi sollte dir genau sagen, daß es dort ein Problem gibt. (es müßte eine Compiler-Warnung vorhanden sein)

Ups... Der Text ist erst nach dem Quoten da.. Cool... Fehler in der DP?!

Warnings... ja :oops: noch 17900! Ich denke ich gebe es mal auf....

Mavarik

[mquadrat]

17.900???? :shock:

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

[himitsu]

War ich wohl schneller mit Editieren, als du mit dem Lesen :mrgreen:

Joar, bei uns in der Software gibt es auch noch gefühlte 2 Milliarden Warnungen, angefangen von nichtinitialisierten Variablen und Results, bis hin zu ein paar dieser Unicodewarnungen (bin auch schon fleißig am entfernen ... im FinalBuilder muß man manchmal ganz schön suchen, bis man den Fehler zwischen den unzähligen Warungen und Hinweisen findet ... das nervt etwas :? )

[Mavarik]

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

Das Problem ist die Verschachtelung...

Das beseitigen einer Warnung zieht eine "Rattenschwanz" von Änderungen von Proc zu Proc nach sich...

Ach ja 64Bit kann ich überhaupt nicht compilieren... Da hagelt es nur Interne-Fehlermeldungen vom Compiler... Aber das ist eine andere Geschichte... *heul* 4 Wochen Arbeit... Ergebinss: Besser lassen!

Delphi 6 ist doch sehr schön...

Mavarik

[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