Hallo.

Borland will ja bald seine Delphi-VCLs Unicode-tauglich machen. Es gibt zwar jetzt schon kommerzielle Komponenten, mit denen man Unicode gut handhaben kann, doch sind diese für OpenSource-Entwickler für mich nicht zu gebrauchen.

Ich habe fast die Vermutung, dass Delphi die falsche Programmiersprache ist, wenn man Unicode möchte. Die VCL dürfte das kleinere Übel sein.

Ich habe mir mal folgendes Beispielprogramm ausgedacht und sehe, dass Unicode quasi unmöglich ist:

1. Das Programm bekommt einen Unicodenamen über die Befehlszeile.
> Geht nicht. ParamStr() gibt nur einen String von sich, keinen Widestring!

2. Der Dateiname soll in einer Editbox dargestellt werden.
> Würde gehen, wenn VCL Unicode geeignet.

3. Die Datei soll nun umbenannt werden.
> Geht, wenn man MoveFileW() anstelle von MoveFile() verwendet.

4. In die Datei soll mit einer Nicht-API-Funktion geschrieben werden.
> Keine Ahnung. Deklaration von AssignFile() ist nicht innerhalb der System.pas aufzufinden.

Am meisten machen mir also die Befehlszeile (ParamStr) und die Nicht-API-Funktionen von Delphi sorgen.

Das blöde ist außerdem, dass ich nicht in den Genuss der neusten Delphi Versionen wie z.B. 2008 kommen werde. Als OpenSource-Entwickler bin ich sehr froh, Turbo-Delphi kostenlos nutzen zu dürfen. Würde ich kommerzielle VCLs nutzen, könnten andere Entwickler meinen Source nicht weiterverwenden.

Was meint ihr? Ist Delphi der falsche Weg, wenn man an Unicode denkt? Ich bin mir sicher, Microsoft hat in VC++ etc. absolut keine Probleme mit Unicode.

Gruß
blackdrake

Zitat:

1. Das Programm bekommt einen Unicodenamen über die Befehlszeile.
> Geht nicht. ParamStr() gibt nur einen String von sich, keinen Widestring!

Ab D2009 ist der StandardString von Delphi ein UnicodeString

Zitat:

2. Der Dateiname soll in einer Editbox dargestellt werden.
> Würde gehen, wenn VCL Unicode geeignet.

Ab D2009 ist das der Fall

Zitat:

3. Die Datei soll nun umbenannt werden.
> Geht, wenn man MoveFileW() anstelle von MoveFile() verwendet.

Dito

Zitat:

4. In die Datei soll mit einer Nicht-API-Funktion geschrieben werden.
> Keine Ahnung. Deklaration von AssignFile() ist nicht innerhalb der System.pas aufzufinden.

System.pas ist nur ein Dummy

Also unsere Anwendung ist (dank ElPack und ein bischen TNTWare) seit 2002 mit Delphi 6 Unicodefähig. Selbst unter Win98 (bis vor kurzen noch Win95) können wir Unicode in der GUI ohne jedliche Installation (passender Font vorrausgesetzt). Welches VC++ oder .NET kann das

Man kann sich ein ParamStrW selbst basteln. Gibt hier einen Eintrag in der Library der zeigt, wie das geht.

In Dateien schreiben geht mit Sachen wie den TNTFileStream wunderbar. Könnte man sich wahrscheinlich auch aus dem Code von TFileStream und ersetzen der Api-Aufrufe durch die entsprechende *W-Variante selbst zusammenbauen.

Insofern: Mit etwas Mehraufwand bekommt man seine Anwendung durchaus Unicode-fähig.

Zitat von mkinzler:

Ab D2009 ist der StandardString von Delphi ein UnicodeString

Würde das bedeuten, dass man den Code einfach portieren kann, ohne sich Gedanken über Unicode und WideStrings zu machen?

Sprich - Kompiliert in Turbo-Delphi eine Non-Unicode-Anwendung, kompiliert in D2009 eine Unicode-Anwendung?

Würde man jedoch in D2009 kompilieren ... gäbe es dann nicht Inkompatibilitätsprobleme mit älteren Windows Versionen (W95 *räusper*)?

Zitat von Bernhard Geyer:

Also unsere Anwendung ist (dank ElPack und ein bischen TNTWare) seit 2002 mit Delphi 6 Unicodefähig. Selbst unter Win98 (bis vor kurzen noch Win95) können wir Unicode in der GUI ohne jedliche Installation (passender Font vorrausgesetzt). Welches VC++ oder .NET kann das Smile

ElPack habe ich zufälligerweise, weil ich aufgrund eines Bannerexchanges für Freeware-Entwickler eine Frei-Lizenz erhalten habe. Aber für OpenSource wie gesagt makaber, weil dann der Code nur noch für mich und ElPack-Besitzer einsehbar/veränderbar wäre.

TNTWare ist ja leider kommerziell geworden. Als es noch Freeware war, hatte man fast die perfekte Lösung.

Zitat von Gausi:

Man kann sich ein ParamStrW selbst basteln. Gibt hier einen Eintrag in der Library der zeigt, wie das geht.

Das geht? Muss ich gleich mal suchen. Vielen Dank für den Hinweis.

Ich müsste mir mal einen Plan machen, welche Stellen der Dateiname in meinem Programm passiert, sodass ich alle Non-Unicode-Funktionen versuchen kann, zu umgehen oder zu ersetzen.

Gruß
blackdrake

Hast du dich mal mit Lazarus auseinandergesetzt ? Dort wird Unicode wesentlich weiter unterstützt und man braucht keine Zusatzkomponenten. Ausserdem, ist Lazarus selbst ja Open Source und dürfte dir damit wesentlich mehr zusagen.

Zitat:

Würde das bedeuten, dass man den Code einfach portieren kann, ohne sich Gedanken über Unicode und WideStrings zu machen?

Ja und Nein. UnicodeString ist nicht WideString sondern ein unicodefähiger Stringtyp

Zitat:

Sprich - Kompiliert in Turbo-Delphi eine Non-Unicode-Anwendung, kompiliert in D2009 eine Unicode-Anwendung?

Ja

Zitat:

Würde man jedoch in D2009 kompilieren ... gäbe es dann nicht Inkompatibilitätsprobleme mit älteren Windows Versionen (W95 *räusper*)?

Nein.

Zitat von mkinzler:

Zitat:

Würde das bedeuten, dass man den Code einfach portieren kann, ohne sich Gedanken über Unicode und WideStrings zu machen?

Ja und Nein. UnicodeString ist nicht WideString sondern ein unicodefähiger Stringtyp

Zitat:

Sprich - Kompiliert in Turbo-Delphi eine Non-Unicode-Anwendung, kompiliert in D2009 eine Unicode-Anwendung?

Ja

Vorsicht mit sowas! Das kommt sehr darauf an, was man in seiner Anwendung mit den Strings macht. Sobald man irgendwo die Eigenschaft benutzt, dass ein Zeichen ein Byte beansprucht, muss man umstrukturieren. Das wurde ja auch auf den Delphi-Tagen am Ende erläutert.

Zitat von blackdrake:

Würde das bedeuten, dass man den Code einfach portieren kann, ohne sich Gedanken über Unicode und WideStrings zu machen?

Zu 95-100% Ja. Je nachdem wie gut/fehlerfrei dein Code ist.

Zitat von blackdrake:

Würde man jedoch in D2009 kompilieren ... gäbe es dann nicht Inkompatibilitätsprobleme mit älteren Windows Versionen (W95 *räusper*)?

Win9x wird nicht mehr unterstützt (AFAIK seit D7 oder D2005). Mit D2007 laufen zwar die Apps noch (nach entsprechenden IE-Update), aber es ist keine unterstützte Plattform mehr (Nachdem W95 eher schon an der Promillegrenze scheidert von Rest-PC's ist dies irrelevant).

Zitat von Bernhard Geyer:

ElPack habe ich zufälligerweise, weil ich aufgrund eines Bannerexchanges für Freeware-Entwickler eine Frei-Lizenz erhalten habe. Aber für OpenSource wie gesagt makaber, weil dann der Code nur noch für mich und ElPack-Besitzer einsehbar/veränderbar wäre.

Man kann nicht alles haben

Zitat von Bernhard Geyer:

TNTWare ist ja leider kommerziell geworden.

War die einzigle Lösung das TNT noch weiterentwickelt wurde nachdem Troy sich zurückgezogen hat.

Zitat von Bernhard Geyer:

Man kann sich ein ParamStrW selbst basteln. Gibt hier einen Eintrag in der Library der zeigt, wie das geht.

Du hast doch TNTWare. Dort ist dach doch gemacht worden

Zitat von christian_u:

Hast du dich mal mit Lazarus auseinandergesetzt ? Dort wird Unicode wesentlich weiter unterstützt und man braucht keine Zusatzkomponenten. Ausserdem, ist Lazarus selbst ja Open Source und dürfte dir damit wesentlich mehr zusagen.

Ein OpenSource Delphi mit mehr Unicodesupport? Klingt ja wie in Bizarrowelt

Vielen Dank für den Hinweis. Ich werd es mir mal anschauen. Ich befürchte aber, dass man seine Projekte nicht einfach reinschieben und sofort wieder nutzen kann (jedoch unter der Annahme, dass man nur Standard-VCLs sowie die Indy's nutzt). Ich werde das Programm trotzdem mal genauer testen.

Zitat von Bernhard Geyer:

Du hast doch TNTWare. Dort ist dach doch gemacht worden

Wenn du mich meinst, ich habe leider kein TNTWare. Als es noch Freeware war, hatte ich mir über Unicode gar keine Gedanken gemacht und habe TNT daher auch nicht genutzt.