Ist wahres Unicode mit Delphi überhaupt möglich?

[blackdrake]

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

[mkinzler]

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

[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 :-)

[Gausi]

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. ;-)

[blackdrake]

Zitat:

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:

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:

Zitat von Gausi

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

Das geht? :shock: 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

[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.

[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

Zitat:

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

Nein.

[Gausi]

Zitat:

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. ;-)

[Bernhard Geyer]

Zitat:

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:

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:

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:

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:

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

[blackdrake]

Zitat:

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:

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.

[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.

[Zacherl]

* Tiburon haben will :stupid: *

Scheint nur so, als würden dann genau die Leute Probleme bekommen, die gerne mal einen String als Array verwendet haben. Wie ist es eigentlich damit:

Delphi-Quellcode:

SetLength(MyString, DataLen);
CopyMemory(@MyString[1], @Data[0], DataLen);

Wobei Data ein ByteArray ist, in dem jedes Byte ein Zeichen ist? Wird dann vermutlich alles falsch in MyString kopiert und MyString bekommt die doppelte Länge, die nötig wäre, da mit jedem neuen Element 2 Bytes hinzugefügt werden oder?

Gruß Zacherl

[Daniel]

Ich habe es eben ausprobiert. Das geht tatsächlich nur dann, wenn man MyString als "AnsiString" deklariert.

Ich sehe hier allerdings auch kaum Raum für implizite Konvertierungen. "CopyMemory()" ist schon eine Sache für sich. ;-)

// EDIT:

Ich bin mir nicht sicher, ob ich Dich richtig verstanden habe. Das war mein Test-Code:

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
var MyString : AnsiString;
        data : array[0..4] of byte;
     DataLen : integer;
begin

  DataLen:= SizeOf(Data);
  data[0]:= 72;  // H
  data[1]:= 65;  // A
  data[2]:= 76;  // L
  data[3]:= 76;  // L
  data[4]:= 79;  // O

  SetLength(MyString, DataLen);
  CopyMemory(@MyString[1], @Data[0], DataLen);

  ShowMessage( MyString );
end;

[Zacherl]

Ah vielen Dank fürs Teste :) War genau das, was ich wissen wollte.

[Assertor]

Zitat:

Zitat von Gausi

Vor der Übernahme durch TMS standen die TNT Unicode Controls unter der LGPL.

Wo hast Du die Info den her? Troy hatte seine Komponente unter einer eigenen, proprietären Lizenz. Vergleichbar MIT/BSD.

Zitat:

Zitat von Daniel

Ich bin von CodeGear autorisiert, diese Beta-Informationen zu veröffentlichen aber auch verpflichtet, diesen Nachsatz stets zu erwähnen.

:zwinker:

Gruß Assertor

[Gausi]

Zitat:

Zitat von Assertor

Zitat:

Zitat von Gausi

Vor der Übernahme durch TMS standen die TNT Unicode Controls unter der LGPL.

Wo hast Du die Info den her? Troy hatte seine Komponente unter einer eigenen, proprietären Lizenz. Vergleichbar MIT/BSD.

:oops: Da hab ich wohl was verwechselt. Hast recht.

[Assertor]

Zitat:

Zitat von Gausi

:oops: Da hab ich wohl was verwechselt. Hast recht.

Ok. Macht ja nichts.

:dp:

[p80286]

Hallo Zacherl,

die Trickser steigen dann einfach von "Array of Byte" auf "Array of Word" um.
Nur die Kompatibilität von "packed Array of Char" mit String ist dann dahin, oder ist Char dann auch ein 16Bit Wert? Wo bleibt dann der 8Bit-Char?

Gruß
K-H

[Daniel]

Der Datentyp Char ist jetzt ein 16bit-Wert. Wer auch künftig den alten Char haben mag, der benutzt AnsiChar/PansiChar.

"packed array of char" und "string" ist in sich wieder konsistent - alles unicode. Kann ich aber gern später mal ausprobieren - bis zum heutigen Tage habe ich das Konstrukt "packed array of char" nie explizit genutzt.

[Roaster]

Zitat:

Zitat von Daniel

Delphi-Quellcode:

[...]
{Auszug aus der System.poas von Tiburón} 
[...]

Heißt die wirklich System.poas jetzt? Wohl eher nicht, war ja augenscheinlich ein eigener Kommentar ;-)

[Roaster]

Zitat:

Zitat von Daniel

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.

Daniel, hast du zufällig eine Ahnung, ob Konstrukte wie MeinString[1] noch so funktionieren wie bisher? Man hat dies ja teilweise ausgiebig verwendet um auf die Anfangsadresse des Strings zu verweisen.

[Daniel]

Zitat:

Zitat von Roaster

Heißt die wirklich System.poas jetzt?

Ja. Alle .PAS-Dateien müssen per Hand in .POAS umbenannt werden. Und zwar vor jedem Compilieren - und danach wieder zurück. Aber vielleicht habe ich da auch nur etwas falsch verstanden, etwas aufwändig ist es nämlich schon.
:stupid:

Zitat:

Zitat von Roaster

Daniel, hast du zufällig eine Ahnung, ob Konstrukte wie MeinString[1] noch so funktionieren wie bisher? Man hat dies ja teilweise ausgiebig verwendet um auf die Anfangsadresse des Strings zu verweisen.

Der Zugriff auf einzelne String-Elemente ist wie bisher möglich. Oder wie meintest Du das jetzt?

Delphi-Quellcode:

(* Auszug aus der unit1.poas ;-) *)
procedure TForm11.Button2Click(Sender: TObject);
var MeinString : string;
begin
  MeinString:= 'Hallo';
  ShowMessage( MeinString );  // zeigt 'Hallo'

  MeinString[1]:= 'Y';
  ShowMessage( MeinString );  // zeigt 'Yallo'
end;

// EDIT:

Oder meinst Du vielleicht sowas wie da im Aufruf von DrawText() ?

Delphi-Quellcode:

(* Quick & Dirty aus der uni1.poas *)
procedure TForm11.Button2Click(Sender: TObject);
var MeinString : string;
         oRect : TRect;
begin
  MeinString:= 'Hallo';

  oRect:= Rect( 10, 10, 200, 200 );
  DrawText( form1.canvas.handle, PChar(@MeinString[1]), 5, oRect, DT_SINGLELINE );
end;

[Roaster]

Zitat:

Zitat von Daniel

Ja. Alle .PAS-Dateien müssen per Hand in .POAS umbenannt werden. Und zwar vor jedem Compilieren - und danach wieder zurück. Aber vielleicht habe ich da auch nur etwas falsch verstanden, etwas aufwändig ist es nämlich schon.

LOL - BIG LOL :lol:

Zitat:

Zitat von Daniel

Der Zugriff auf einzelne String-Elemente ist wie bisher möglich. Oder wie meintest Du das jetzt?

Ja, das meinte ich...

Zitat:

Zitat von Daniel

Delphi-Quellcode:

(* Auszug aus der unit1.poas ;-) *)

Hehe!

Zitat:

Zitat von Daniel

Delphi-Quellcode:

procedure TForm11.Button2Click(Sender: TObject);
var MeinString : string;
begin
  MeinString:= 'Hallo';
  ShowMessage( MeinString );  // zeigt 'Hallo'

  MeinString[1]:= 'Y';
  ShowMessage( MeinString );  // zeigt 'Yallo'
end;

Ich nehme mal an, dass das hier aus Tiburon stammt. Mit anderen Worten, ich kann einzelne Zeichen eines Strings wie gewohnt ersetzen. Sieht so aus als ob sich der Compiler automatisch um die Länge eines einzelnen Zeichens beim Einfügen kümmert

Zitat:

Zitat von Daniel

Oder meinst Du vielleicht sowas wie da im Aufruf von DrawText() ?

Delphi-Quellcode:

(* Quick & Dirty aus der uni1.poas *)
procedure TForm11.Button2Click(Sender: TObject);
var MeinString : string;
         oRect : TRect;
begin
  MeinString:= 'Hallo';

  oRect:= Rect( 10, 10, 200, 200 );
  DrawText( form1.canvas.handle, PChar(@MeinString[1]), 5, oRect, DT_SINGLELINE );
end;

Ja, auch das meinte ich damit. Wird wohl auch einwandfrei funktionieren, da PChar zukünftig ein PWideChar ist und somit alles paletti ist.

Danke! Man wird ja richtig heiß auf das neue Delphi :wink:

[Der.Kaktus]

[quote="Roaster"]

Zitat:

Zitat von Daniel

Ja. Alle .PAS-Dateien müssen per Hand in .POAS umbenannt werden. Und zwar vor jedem Compilieren - und danach wieder zurück. Aber vielleicht habe ich da auch nur etwas falsch verstanden, etwas aufwändig ist es nämlich schon.

LOL - BIG LOL :lol:

Zitat:

Zitat von Daniel

Der Zugriff auf einzelne String-Elemente ist wie bisher möglich. Oder wie meintest Du das jetzt?

Ja, das meinte ich...

Zitat:

Zitat von Daniel

Delphi-Quellcode:

(* Auszug aus der unit1.poas ;-) *)

Hehe!

Zitat:

Zitat von Daniel

Delphi-Quellcode:

procedure TForm11.Button2Click(Sender: TObject);
var MeinString : string;
begin
  MeinString:= 'Hallo';
  ShowMessage( MeinString );  // zeigt 'Hallo'

  MeinString[1]:= 'Y';
  ShowMessage( MeinString );  // zeigt 'Yallo'
end;

.....

Soviel zu [OT] [/OT] *fg* :-D

[Zacherl]

Wie stehts eigentlich mit Ribbon Komponenten? Habe auf einem Screenshot zu Tiburon (in irgendeinem der Entwickler / Tester Blogs) eine neue Kategorie mit diesen Komponenten gesehen. Oder handelt es sich um DevExpress Bars oder sowas in der Art?

[Roaster]

Zitat:

Zitat von Zacherl

Wie stehts eigentlich mit Ribbon Komponenten? Habe auf einem Screenshot zu Tiburon (in irgendeinem der Entwickler / Tester Blogs) eine neue Kategorie mit diesen Komponenten gesehen. Oder handelt es sich um DevExpress Bars oder sowas in der Art?

Komplett neu, angeblich eine Eigenentwicklung von CodeGear.

[toms]

Zitat:

Zitat von Zacherl

Wie stehts eigentlich mit Ribbon Komponenten? Habe auf einem Screenshot zu Tiburon (in irgendeinem der Entwickler / Tester Blogs) eine neue Kategorie mit diesen Komponenten gesehen. Oder handelt es sich um DevExpress Bars oder sowas in der Art?

Some new and enhanced components coming in Tiburon

[Zacherl]

Klingt ja richtig cool :) Mal abwarten, ob die von CodeGear besser sind als die von DevExpress (hab die mal getestet und war voll und ganz zufrieden .. so ist das ja nicht :mrgreen: )

€: @toms: Mh irgendwie stehen da zwar viele Komponenten, aber nichts über die Ribbons. Oder bin ich mal wieder blind :D

[grenzgaenger]

Zitat:

Zitat von Roaster

Zitat:

Zitat von Daniel

Ja. Alle .PAS-Dateien müssen per Hand in .POAS umbenannt werden. Und zwar vor jedem Compilieren - und danach wieder zurück. Aber vielleicht habe ich da auch nur etwas falsch verstanden, etwas aufwändig ist es nämlich schon.

Zitat:

Zitat von Daniel

Oder meinst Du vielleicht sowas wie da im Aufruf von DrawText() ?

Delphi-Quellcode:

(* Quick & Dirty aus der uni1.poas *)
procedure TForm11.Button2Click(Sender: TObject);
var MeinString : string;
         oRect : TRect;
begin
  MeinString:= 'Hallo';

  oRect:= Rect( 10, 10, 200, 200 );
  DrawText( form1.canvas.handle, PChar(@MeinString[1]), 5, oRect, DT_SINGLELINE );
end;

Ja, auch das meinte ich damit. Wird wohl auch einwandfrei funktionieren, da PChar zukünftig ein PWideChar ist und somit alles paletti ist.

Danke! Man wird ja richtig heiß auf das neue Delphi :wink:

wenn du es ausprobieren willst, kannste das schon seit TP1... das array mit 'n anderen datentyp ersetzen und der zugriff funktioniert immer noch richtig über den index :-)

das stimmt natürlich nur, wenn daniel auch nicht gefakted hat und in wirklichkeit was ganz anderes macht als den typ von CHAR von 1 nach 2 byte aufzuboren :mrgreen:

[grenzgaenger]

Zitat:

Zitat von Zacherl

Klingt ja richtig cool :) Mal abwarten, ob die von CodeGear besser sind als die von DevExpress (hab die mal getestet und war voll und ganz zufrieden .. so ist das ja nicht :mrgreen: )

€: @toms: Mh irgendwie stehen da zwar viele Komponenten, aber nichts über die Ribbons. Oder bin ich mal wieder blind :D

die dev. express sind halt nur halb entwickelt, so wie halt bei den amis immer...

wenn du mal versuchst 'n skin einzusetzen, von wem auch immer... merkste es rasch...

aber sonst, ist devexpress mit das beste was auf dem komponentenmarkt zur verfügung steht... und sie versuchen auch (mehr oder weniger) die lücken zu beheben.

aber 'n ansporn wirds für die jungs :-) . sowohl devexpress als auch für die CG's.. die sich ja zur zeit wieder bewegen :-) . und schlecht sind die CG's nicht... die wurden halt nur die letzten jahre nur an der kurzen leine gehalten... hoffen wir mal, dass sich mit dem unlashed neue dimensionen erschliessen :-)

[Zacherl]

Jap hab das bei DevExpress auch gemerkt. Z.b. mit transparenten PNGs gibts Probleme, wenn das XP Manifest aktiviert ist, wobei das Problem mit 20 Zeilen Code zu fixen ist. Stattdessen haben die jetzt eine Warnung eingeblendet, wenn ein XP Manifest vorhanden ist :mrgreen:

Naja bin wirklich mal gespannt auf die CG Dinger. Die werden dann ja auch schön Unicode fähig sein :love: