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

[milo]

Zitat:

Zitat von Mavarik (Beitrag 1125749)

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

Tja, lieber Frank. :? Dann wirst Du wohl einen Teil Deiner umfangreichen Bibliothek ändern müssen.

Wir benutzen auch noch Routinen die im letzten Jahrtausend geschrieben wurden, aber die machen offensichtlich nicht solche Dinge wie Du. :?: Dabei kann ich mich daran erinnern, dass Du auch immer ein wenig in den Sourcen der Libraries gearbeitet hast, um Dir bestimmte Sachen einfacher zu machen. Das rächt sich vermutlich jetzt. :oops:

Zur Zeit habe ich mir mal testweise Windows 8 unter einer VM8 Workstation installiert. Einfach mal nur um zu sehen ob unsere Programme überhaupt noch laufen. :-D Allerdings würde ich nie auf die Idee kommen "Delphi 1" oder "Turbo Pascal für Windows" darauf zu installieren und Alt-Programme konvertieren. Du sicher auch nicht, aber erwarte auch nicht, dass die neuen Compiler immer noch mit den alten Sourcen aus Deiner DOSenzeit umgehen können müssen sollen wollen. Denn dann hätten wir die hübschen drehenden Würfel doch nicht ...

Achja: Ich habe nicht einmal mehr einen DOS-Editor. Auch wenn mein erstes Windows die Versionsnummer 2 und mein erstes DOS die Versionsnummer 3.x hatte ...

Gruß :-D Milo

[Mavarik]

Zitat:

Zitat von milo (Beitrag 1125780)

Dabei kann ich mich daran erinnern, dass Du auch immer ein wenig in den Sourcen der Libraries gearbeitet hast, um Dir bestimmte Sachen einfacher zu machen. Das rächt sich vermutlich jetzt. :oops:

Da musst Du mich verwechseln... Habe noch NIE die Sourcen der Lib geändert...

Mavarik :coder:

[milo]

Zitat:

Zitat von Mavarik (Beitrag 1125793)

Zitat:

Zitat von milo (Beitrag 1125780)

Dabei kann ich mich daran erinnern, dass Du auch immer ein wenig in den Sourcen der Libraries gearbeitet hast, um Dir bestimmte Sachen einfacher zu machen. Das rächt sich vermutlich jetzt. :oops:

Da musst Du mich verwechseln... Habe noch NIE die Sourcen der Lib geändert...

Mavarik :coder:

Da muss ich Dich wohl verwechseln... :lol:

Gruß :-D Milo

[ede57]

Zitat:

Achja: Ich habe nicht einmal mehr einen DOS-Editor. Auch wenn mein erstes Windows die Versionsnummer 2 und mein erstes DOS die Versionsnummer 3.x hatte ...

Da kannst mal sehen wie du dein Windows kennst

CMD
Edit
Version 2.0026 von 1995

Dann haste eine DOS Editor.

[milo]

Zitat:

Zitat von ede57 (Beitrag 1125858)

Zitat:

Achja: Ich habe nicht einmal mehr einen DOS-Editor. Auch wenn mein erstes Windows die Versionsnummer 2 und mein erstes DOS die Versionsnummer 3.x hatte ...

Da kannst mal sehen wie du dein Windows kennst

CMD
Edit
Version 2.0026 von 1995

Dann haste eine DOS Editor.

Das Zeug war mir immer schon suspekt. Wäre ich mal bei meinem Apple IIc geblieben ... *seufz*

Gruß Milo

[Mavarik]

Zitat:

Zitat von milo (Beitrag 1125860)

Das Zeug war mir immer schon suspekt. Wäre ich mal bei meinem Apple IIc geblieben ... *seufz*

Gruß Milo

Ja das waren noch Zeiten...SeaDragon & Castle Wulfenstein...

;-)

[Uwe Raabe]

Zitat:

Zitat von ede57 (Beitrag 1125858)

Da kannst mal sehen wie du dein Windows kennst

CMD
Edit
Version 2.0026 von 1995

Dann haste eine DOS Editor.

Zitat:

C:\>edit
Der Befehl "edit" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.

Windows 7 x64

[Union]

Nicht nur Edit wurde aus der 64-bit Version entfernt sondern auch mein persönlicher Favorit Edlin. Und man kann keine PUN: Anschlüsse mehr konfigurieren ;)

[Uwe Raabe]

Zitat:

Zitat von Union (Beitrag 1125884)

Nicht nur Edit wurde aus der 64-bit Version entfernt sondern auch mein persönlicher Favorit Edlin. Und man kann keine PUN: Anschlüsse mehr konfigurieren ;)

Dafür können die Lochkarten aber auch mehr als 80 Zeichen fassen...