Ist wahres Unicode mit Delphi überhaupt möglich?

[mkinzler]

http://www.yunqa.de/delphi/doku.php/...controls/index
http://www.mh-nexus.de/tntunicodecontrols.htm

[christian_u]

Zitat:

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.

Die LCL (Lazarus Component Library) ist weitestgehend kompatibel zur VCL. Es kommt immer drauf an was du nutzt, und wie komplex deine projekte sind. Es ist etwas aufwand Projekte anzupassen und einige dinge werden auch nicht funktionieren. Solang man Standart VCL Komponenten nutzt wird die erfolgsquote bei ca 90% liegen. Bei Winapi vieleicht noch bei 30%. Kommt auch aufs Betriebsystem und Widgetset an Lazarus unterstützt ja auch MacOS und Linux. Auf Windows läuft der WinAPI kram natürlich 100%. Indy ist sone Sache. Das ding ist an sich schon so verbuggt das die paar bugs die durchs Lazarus hinzukommen das eigentlich unbenutzbar machen. Da würd ich ernsthaft darüber nachdenken was saubereres zu nehmen. Synapse z.b. das läuft unter Delphi wie Lazarus 1:1 oder LNet da weiss ich allerdings nicht obs ein Delphi package gibt.

[sirius]

Zitat:

Zitat von blackdrake

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

Das liegt daran, dass dich die Funktion paramStr(0) derzeit auf die WinAPI "GetModuleFileNameA" schickt. Dabei steht das A für Ansi. Es gibt aber auch die Funktion "GetModuleFileNameW" Wie du sieht, eine kleine Änderung mit großen Wirkungen :mrgreen:
Delphi ist ja soweit gegangen, dass es die Funktion "GetModuleFileName" implementiert und gleich auf GetModuleFileNameW umleitet. Schau mal in die Unit Windows!

Mit allen weiteren Funktionen verhält es sich ähnlich. Wenn man String plötzlich als WideString und die Funktionen der WinAPI anders lenkt ist schon ein großer Teil geschafft (zumindest für Windows-like-UniCode).
Aber der Teufel steckt sicher auch da noch in diversen Detaild. Dass der ausgetrieben wird, dafür bezahlen wir ja schließlich auch Borland...äh...CodeGear...äh...Emdingsdabums

[Daniel]

Ich habe eben mal nachgesehen - und es ist (wie erwartet) wirklich so, dass GetCommandLine (und dieser Funktion bedient sich ParamStr()) per Standard auf die Unicode-Variante zugreift. Du hast darüber hinaus noch die Möglichkeit, explizit auf die Ansi-Variante zuzugreifen, sofern Dir dies ein Bedürfnis ist.

Delphi-Quellcode:

[...]
{Auszug aus der System.poas von Tiburón}
function GetCommandLineA: PAnsiChar; stdcall; external kernel name 'GetCommandLineA';
function GetCommandLineW: PWideChar; stdcall; external kernel name 'GetCommandLineW';
{$IFNDEF UNICODE}
function GetCommandLine: PAnsiChar; stdcall; external kernel name 'GetCommandLineA';
{$ELSE}
function GetCommandLine: PWideChar; stdcall; external kernel name 'GetCommandLineW';
{$ENDIF}
[...]

Um dem Protokoll Genüge zu tun: Ich bin von CodeGear autorisiert, diese Beta-Informationen zu veröffentlichen aber auch verpflichtet, diesen Nachsatz stets zu erwähnen.

[blackdrake]

Zitat:

Zitat von mkinzler

http://www.yunqa.de/delphi/doku.php/products/tntunicodecontrols/index
http://www.mh-nexus.de/tntunicodecontrols.htm

Irgendwie bin ich jetzt ein wenig verwirrt. Ist das jetzt Freeware? Ich dachte, das Teil wäre aufgekauft worden und kostet nun ca. 70 Euro. Oder sind das alte Versionen der VCL?

Zitat:

Zitat von Daniel

Ich habe eben mal nachgesehen - und es ist (wie erwartet) wirklich so, dass GetCommandLine (und dieser Funktion bedient sich ParamStr()) per Standard auf die Unicode-Variante zugreift. Du hast darüber hinaus noch die Möglichkeit, explizit auf die Ansi-Variante zuzugreifen, sofern Dir dies ein Bedürfnis ist.

Ui. Ich vergesse immer, dass so viel von der API abgeleitet ist. Ich dachte nicht, dass ParamStr() sich auch der API bedient, deswegen hatte ich nicht nachverfolgt.

Zu meinem Fall: Meine Datei würde über ParamStr (API +W) oder OpenDialog (Ext.VCL) reinkommen. Anschließend in einem Label (Ext.VCL) dargestellt. Danach per Indy per POST an einer Webseite gesendet. Indy scheint WideStrings soweit ich das sehe bei MultiPartData-AddFile() zu akzeptieren (aber Source ist nicht bei Turbo-Delphi dabei). Jetzt müsste ich mich um die externen VCLs OpenDialog und Label kümmern.

[Bernhard Geyer]

Zitat:

Zitat von Daniel

Ich habe eben mal nachgesehen - und es ist (wie erwartet) wirklich so, dass GetCommandLine...
Um dem Protokoll Genüge zu tun: Ich bin von CodeGear autorisiert, diese Beta-Informationen zu veröffentlichen aber auch verpflichtet, diesen Nachsatz stets zu erwähnen.

Darfst du auch den Inhalt der Funktion ParamStr posten um zu sehen wie intern dieser Aufruf erfolgt?
Eigentlich müßt ja viel mit PChar dortstehen und je nach Compilerschalter is PChar = PAnsiChar bzw. PChar = PWideChar.

[Daniel]

Zitat:

Zitat von Bernhard Geyer

Eigentlich müßt ja viel mit PChar dortstehen und je nach Compilerschalter is PChar = PAnsiChar bzw. PChar = PWideChar.

Ja, nein, doch - also eigentlich nein.

In Delphi 2009 ist PChar = PWideChar. Da führt kein Weg dran vorbei. Wenn Du den "alten" Char möchtest, bei dem noch 1 Zeichen = 1 Byte war, dann musst Du explizit PAnsiChar verwenden. Analog gilt Gleiches für Strings.

In sich ist das System also weiterhin stimmig und deswegen ging das mit der Portierung auf weiten Strecken auch recht flott. Man biegt den API-Aufruf auf die "W"-Variante um und - wenigstens in diesem Fall - am Ziel. Dieses Prinzip funktioniert auf weiten Strecken der Portierung, bis genau zu der Stelle, an der man nicht sauber mit SizeOf() und Konsorten gearbeitet hat, sondern den String in seine Bytes zu zerlegen versucht.

[Gausi]

Vor der Übernahme durch TMS standen die TNT Unicode Controls unter der LGPL. Diese etwas älteren Versionen findet man immer noch auf diversen Seiten unter eben dieser Lizenz. Die aktuellsten Versionen muss man dann bei TMS kaufen, wenn man sie braucht.

[Dezipaitor]

Zumindest sind die JEDI Projekte JVCL, JCL (größte Teile), API und WSCL für die neue Version gerüstet.

[Daniel]

Noch mal kurz zur Demonstration:

Ich habe mein Vista mal auf Japanisch umgestellt. Das hat beispielsweise im Dateisystem die für Vista typische Lokalisierung einiger Ordner zur Folge.

Wenn man nun mit den üblichen API-Funktionen diese Namen ermitteln will, nimmt man einfach seinen alten Code. Dadurch, dass die korrekte API-Funktion aufgerufen wird und sowohl Char als auch String unicode-fähig sind, hat man wieder ein in sich konsistentes System:

Delphi-Quellcode:

(* Der Code ist nicht hübsch, aber er tut. *)
procedure TForm1.Button1Click(Sender: TObject);
var root : string;
    sRec : TSearchRec;
    fint : integer;
   fInfo : TSHFileInfo;
begin
  root:= 'c:\';

  fint:= FindFirst( root+'*.*', faAnyFile, sRec );
  while fint = 0 do
  begin
    SHGetFileInfo( PChar(root + srec.name), 0, fInfo, SizeOf(fInfo), SHGFI_DISPLAYNAME OR SHGFI_TYPENAME );
    Memo1.lines.add( fInfo.szDisplayName + ' (' +fInfo.szTypeName+')'  );
    fint:= FindNext( sRec );
  end;
  FindClose( sRec );
end;

Ergebnis mit den Standard-Komponenten siehe Anhang.