Migrations-Probleme -> UniCode

[Mavarik]

Hallo Zusammen...

Als XE erschienen ist... Natürlich nach den Delphi Tagen sofort gekauft...
Mit ENTSETZEN festgestellt, dass es {$H-} nicht mehr gibt und ein Char nicht mehr ein Char ist. (Bitte keine Kommentare dazu ;-)

Also XE wieder weggelegt und entschieden - 2,5 Mio Zeilen Source... No way...

-- Story zu Ende --- { Dachte ich }

Als XE2 erschienen ist...Natürlich nach den Delphi Tagen sofort gekauft...
Mit ENTSETZEN festgestellt... Ach ne hatten wir ja schon mal...

OK Also doch mal durchbeißen...

Kann ja nicht so schwierig sein... Global Renamer programmiert... Char -> AnsiChar...

Tja leider funktioniert das so nicht, denn alle abgeleiteten Funktionen aus der VCL wollen kein AnsiChar, sondern ein Char!

Und jetzt? Erstmal Wochenende... Vielleicht habe ich nächste Woche neuen Mut.

Wie habt Ihr das gemacht? Nur neue Programme mit XE(2) schreiben?

Beispiel: Keypress(Key:Char);

Was kommt den in dem Char an bei Unicode? Und wie mache ich korrekte Typenumwandlung für die interne Verarbeitung die auf AnsiChar aufbaut?

Hat jemand vielleicht einen "Leitfaden"?

Grüsse Mavarik :coder:

[himitsu]

Zitat:

Zitat von Mavarik (Beitrag 1124608)

Tja leider funktioniert das so nicht, denn alle abgeleiteten Funktionen aus der VCL wollen kein AnsiChar, sondern ein Char!

Tja, die VCL ist komplett Unicode, die WinAPI dahinter arbeitet jetzt mit Unicode.

Vorher wurden die Windows auch als ANSI erstellt (weswegen die TNTs es nicht so einfach hatten hier "einfach" Unicode reinzubringen, da man zwar die UnicodeAPIs nutzten könnte, aber dennoch die Fesnter mit ANSI arbeiten).

Für einige ANSI-Funktionen gibt z.B. die Unit AnsiStrings.


Bei einer Umwandlung:
- wenn es nur auf ASCII ankommt, dann einfach die Chars direkt casten
- ansonsten üben den Char konvertieren

[mjustin]

Zitat:

Zitat von himitsu (Beitrag 1124672)

Vorher wurden die Windows auch als ANSI erstellt (weswegen die TNTs es nicht so einfach hatten hier "einfach" Unicode reinzubringen, da man zwar die UnicodeAPIs nutzten könnte, aber dennoch die Fesnter mit ANSI arbeiten).

Arbeitete Windows nicht schon seit einer gefühlten Ewigkeit intern mit Unicode, und hatte je eine Ansi- und eine WideString Version der API Funktionen? Ich hatte es eher so in Erinnerung dass gerade deswegen die TNT Komponenten relativ leicht erstellt werden konnten da "nur" die WinAPI-Aufrufe auf die jeweilige WideString Varianten umdirigiert werden mussten.

[himitsu]

Dennoch arbeiten die Messages mit ANSI, wenn das Window ala ANSI erstellt wurde.

Du bekommst also keinen Unicodetext in ein Edit, wenn dieses nicht als Unicode erstellt wurde.

Zitat:

If you register the window class by using RegisterClassExA, the application tells the system that the windows of the created class expect messages with text or character parameters to use the ANSI character set; if you register it by using RegisterClassExW, the application requests that the system pass text parameters of messages as Unicode.

[mjustin]

Zitat:

Zitat von himitsu (Beitrag 1124722)

Dennoch arbeiten die Messages mit ANSI, wenn das Window ala ANSI erstellt wurde.

Du bekommst also keinen Unicodetext in ein Edit, wenn dieses nicht als Unicode erstellt wurde.

Bei den TNT Komponenten wird es einfach dadurch erreicht, das für TWinControls nachträglich ein Unicode-Handle erszeugt wird:

Code:

To add Unicode support to a TWinControl descendant, override CreateWindowHandle() and call CreateUnicodeHandle()

Der Clou ist laut TNT Doku, dass bei den SendMessageA Aufrufen der VCL an ein Unicode Fenster Windows automatisch die Ansi/Unicode Konvertierung übernimmt.

In TntControls.pas wird das Verfahren beschrieben, liest sich fast wie ein kleiner Roman :)

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1124672)

Bei einer Umwandlung:
- wenn es nur auf ASCII ankommt, dann einfach die Chars direkt casten
- ansonsten üben den Char konvertieren

Fast immer wenn ich hier im Forum einen Beitrag poste - z.B. wenn ich wiedermal an ein Problem gestoßen bin - wundere ich mich darüber wer bzw. wie wenige darauf antworten...

Also etweder programmiert Ihr anders oder ich weis es nicht.

@himitsu Danke, von Dir gibt es eigentlich immer - zu allen Themen ein gute Antwort.

Neues Beispiel...

Nehmt Euch mal nen DOS-Editor... Tippt eine keines "ü" chr(129) in die Datei.
Wenn Ihr diese Datei ins aktuelle Delphi ladet ist das "ü" einfach weg.

Nutzt den keiner von Euch mehr Sourcecode aus der Pre-Windows Area? Ihr müsst doch auf die gleichen Probleme stoßen

Grüsse Mavarik :coder:

[Union]

Zitat:

Sourcecode aus der Pre-Windows Area

Natürlich. Aber den compiliere ich nicht mit Delphi. Und dort immer noch mit D7, weil nach jeder neueren Version passierte mir das gleiche wie Dir

Zitat:

Mit ENTSETZEN festgestellt... Ach ne hatten wir ja schon mal...

.

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1125704)

Fast immer wenn ich hier im Forum einen Beitrag poste - z.B. wenn ich wiedermal an ein Problem gestoßen bin - wundere ich mich darüber wer bzw. wie wenige darauf antworten...

Also etweder programmiert Ihr anders oder ich weis es nicht.

Sieht fast so aus.

Zitat:

Zitat von Mavarik (Beitrag 1125704)

Nutzt den keiner von Euch mehr Sourcecode aus der Pre-Windows Area? Ihr müsst doch auf die gleichen Probleme stoßen

Ich habe meine DOS-Programme schon vor gefühlten 100 Jahren auf Windows portiert - oder sie sind immer noch DOS-Programme und werden mit Borland Pascal bearbeitet.

Grundsätzlich versuche ich, alle Programme immer mit der aktuellen Delphi-Version zu bearbeiten. Nur in seltenen Fällen bin ich gezwungen, eine bestimmte Delphi-Version zu verwenden (aber auch da nerve ich ständig). Natürlich gibt es immer ein gewisses Zeitfenster für die Umstellung z.B. jetzt bei XE2 wegen der Fremdkomponenten. Alles in allem habe ich aber sehr gute Erfahrungen mit dieser Vorgehensweise gemacht. Der Änderungsaufwand ist in den meisten Fällen nur minimal.

[Robotiker]

Zitat:

Zitat von Mavarik (Beitrag 1125704)

Also etweder programmiert Ihr anders oder ich weis es nicht.

Ich glaube meinen Code hat gerettet, dass es beim C++ Builder schon vorher Konvention war immer AnsiString zu schreiben und nie String, schon wegen der Verwechslungsgefahr mit dem C++ Typ string.

Dadurch hatte man nach der Umstellung zwar diverse überflüssige Konvertierungen zwischen Ansi und Unicode. Aber das meiste lief sofort.

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1125718)

Ich habe meine DOS-Programme schon vor gefühlten 100 Jahren auf Windows portiert - oder sie sind immer noch DOS-Programme und werden mit Borland Pascal bearbeitet.

Ja das habe ich auch....DOS Programme gibt es nicht mehr... Wurde alles auf Windows und Delphi umgestellt...

Aber hunderttausende Zeilen Source sind immer noch in Benutzung und zwar bis jetzt unverändert. (War auch bisher nicht nötig)

Mavarik