c++ vs delphi

[tommie-lie]

Zitat von mael:

Tut auch string-handling anbieten was unnötig ist für Pascal.

Kommt drauf an, welche RTL ich verwende. Und ganz ehrlich: ich verwende lieber die String-Funktionen der libc als die der FPC-RTL... Mit Kylix und Delphi hätte ich da weniger Bedenken.

Zitat von mael:

Andere notwendige Sachen sind vorhanden, zumindest habe ich bis jetzt noch nichts gehabt was nicht übersetzt war und wofür pascal nicht selbst was bietet.

Kannst du mir dann auch sagen, wie ich oben genannte POSIX-IPC mit JEDI hinkriege?

Zitat:

Aber zu über 90%, XP konnte vorher nicht sein, aber es gibt ja D7 oder Lischkes Theme-Manager und das sieht genau wie XP aus weil es eben Win-Controls verwendet. VCL ist fast nur ein Wrapper.

Die erweiterten Möglichkeiten des LVs kriegt man damit trotzdem nicht (z.B. Kacheln).
Und warum pinselt man sich Labels selbst auf den Canvas, wenn es doch unter den Windows-Controls so schöne Dinge wie STATICs gibt? *Das* gehört auch dazu, wenn man sämtliche nativen Elemente unterstützen will.

Zitat:

Schau dir mal ne Qt Anwendung mit Themes an...

Sieht schön aus.

Zitat:

Was genau das ist was ich nicht mag, ListView und TreeView von Windows sollten verwendet werden, ich will kein importiertes Linux.

Dann benutz' doch Windows-Anwendungen. Ich sehe nicht, wo dein Problem liegt. Unter Windows kommst du mit GTK und Qt nur dann in Berührung, wenn du auf Linux-Feeling nicht verzichten willst und dir entsprechend portierte Linux-Programme zulegst. Ich wüsste kein Projekt, das von Anfang an ausschließlich für Windows entwickelt wurde und GTK benutzt.
*Ich* will Portability, und ich benutze dafür liebend gerne freie Toolkits.

Zitat:

Da sollte der Window-Manager Standard-Dialog verwendet werden (wie KDE oder GNOME ihn anbieten) und nur wenn nicht vorhanden dann GTK oder Qt Dialoge. Ich habe doch schon gesagt, unter Linux mag ich auch kein importiertes Windows. (siehe Bemerkung zu Kylix)

Und ich habe schon gesagt daß du dann für jeden popeligen Windowmanager eine eigene GUI schreiben müsstest, weil jeder irgendwas anders macht, wenn du für alles immer und überall die native widgets nehmen willst.

Zitat:

Aber ein schlechter Kompromiss, genausogut könnte man die VCL erweitern und Wrapper um die X Window API machen und eventl. noch Window Manager berücksichtigen. Ein ordentlicher Pascal-Wrapper dafür wäre durchaus machbar und von allen verwendbar (wodurch sich die Last verteilt) aber eben nicht auf GTK basiert.

Du hast nie ein reines X-Programm gesehen, oder?

Zitat:

Unsinn, nur Win32 API und X Window API, der Window Manager(für Unix) macht kaum mehr als die Darstellung. Um die Abweichungen muß sich außerdem GTK auch kümmern, und das tut es auch nicht immer so schön.

Du hast tatsächlich nie ein X-Programm gesehen
Wenn du optisch auf das Niveau von Windows kommen willst, hast du schon fast ein fertiges TK, da kannst du auch ein fertiges (GTK, Qt, ...) nehmen.

Zitat:

Stöhn nicht, es geht darum das Windows Software wie Windows Software funktionieren und aussehen muß, gleiches gilt für Linux Software und für Crossplattform.

Windows-Software sieht i.A. wie Windows-Software aus. Linux-Feeling kriegst du nur, wenn du Software, die für Linux entwickelt wurde, nach Windows rüberschleppst.

Zitat:

Ein Programm muß sich an das BS anpassen und nicht sein Heimatland importieren. Wenn ich ins Ausland gehe um dort zu leben lerne ich die Sprache dieses Landes und seine Bräuche.

Schön, wenn du 300 Sprachen kannst, einige Programmierer beschäftigen sich aber mehr mit den Programmfeatures und mit den Bugfixes als mit Oberflächenpolierung auf Systemen, die sie nur aus Gefälligkeit unterstützen, weil die Nachfrage für einen Windows-Port so groß war.

Zitat von mael:

Zitat:

Die haben auch genug maintainer für beide Plattformen. Bei OpenOffice.org hast du sogar im laufenden Betrieb die Wahl zwischen dem OO.o-eigenen (selbstgebastelten) Dialog und den System-Dialogen.

Sag ich ja, geht auch anders.

Ja, mit einem heidenaufwand. An der Native Widget Unterstützung für OpenOffice.org2 hat man über ein Jahr rumentwickelt. Zeit, die man bei kleineren Projekten mit wneiger Entwicklern besser in das Programm selbst stecken sollte.

Zitat von mael:

Zitat von tommie-lie:

Ja, Delphi legt dir auch nicht für jedes Fenster einen eigenen Eintrag in die Taskleiste und behandelt nicht jedes Fenster als getrenntes Fenster, sondern als Unterfenster des Hauptfensters, sodaß bei einem Klick auf ein belibebiges Fenster die gesamte IDE in den Vordergrund kommt. Lazarus macht das nicht.

Das ist natürlich schlecht, solange hab ich mir das nichtmal angesehen.

Ganz ehrlich, ohne dir nahetreten zu wollen, mir scheint, als hättest du dir vieles nicht genau angesehen.

Zitat von mael:

Dann MS VS hat sich gerade mal gemausert da ist jetzt die Borland IDE plötzlich total schlecht? Das finde ich doch etwas unobjektiv.

Meinungen über die Produktivität einer IDE sind immer subjektiv. Es gibt auch Leute, die lieben Lazarus.

[mael]

Zitat:

Zitat von mael:

Tut auch string-handling anbieten was unnötig ist für Pascal.

Kommt drauf an, welche RTL ich verwende. Und ganz ehrlich: ich verwende lieber die String-Funktionen der libc als die der FPC-RTL...

Wenn das so ist, solltest Du sowieso FP sein lassen.

Zitat:

Kannst du mir dann auch sagen, wie ich oben genannte POSIX-IPC mit JEDI hinkriege?

System V IPC Sachen sind in Kylix libc.pas definiert, JEDI hat, bis jetzt, soweit ich weiß dafür keine Unterstützung. Die pthread.h ist aber kurz und schnell übersetzt, also kein wirkliches Hindernis. Wie wäre es: Übersetzte es und schick es auf die JEDI mailing Liste.

Zitat:

Die erweiterten Möglichkeiten des LVs kriegt man damit trotzdem nicht (z.B. Kacheln).

Richtig das fehlt, sowas ist aber kein Konzept-Fehler sowie bei GTK für Windows, sondern ein nicht implementiertes Feature. Sicherlich weit weniger tragisch und vorallem sehr viel leichter zu korrigieren.

Zitat:

Und warum pinselt man sich Labels selbst auf den Canvas, wenn es doch unter den Windows-Controls so schöne Dinge wie STATICs gibt?

Es gibt TStaticText wenn man möchte, Labels sind Resourcenschonender. Gerade unter Win9x sind Fensterresourcen ziemlich begrenzt.

Zitat:

Zitat:

Schau dir mal ne Qt Anwendung mit Themes an...

Sieht schön aus.

Wird nicht korrekt gezeichnet, die Menüs wackeln hin und her, die Shortcuts sind schlecht implementiert, Teile werden nicht gezeichnet (z.B. beim PageControl)

Zitat:

Dann benutz' doch Windows-Anwendungen. Ich sehe nicht, wo dein Problem liegt. Unter Windows kommst du mit GTK und Qt nur dann in Berührung, wenn du auf Linux-Feeling nicht verzichten willst und dir entsprechend portierte Linux-Programme zulegst. Ich wüsste kein Projekt, das von Anfang an ausschließlich für Windows entwickelt wurde und GTK benutzt.
*Ich* will Portability, und ich benutze dafür liebend gerne freie Toolkits.

Du ignorierst einfach was ich sage. Es geht nicht was für Programme ich verwenden will, es geht darum das GTK sich nicht an Windows hält, und auch wenn man Crossplattform ist muß man trotzdem sich ans BS halten wie Firefox. Und daher ist GTK keine gute Basis um Programme zu schreiben. Außerdem werden häufig auch Programme von Windows nach Linux portiert. Z.B. PC-Bibliothek, Qt hat der heutigen Office-Bibliothek nicht gut getan.

Zitat:

Und ich habe schon gesagt daß du dann für jeden popeligen Windowmanager eine eigene GUI schreiben müsstest, weil jeder irgendwas anders macht, wenn du für alles immer und überall die native widgets nehmen willst.

Lies richtig, es geht um die Frameworks. Die sollen sich nach dem Standard richten, wenn sie das tun, mußt DU Dich nicht um die Details kümmern. Die Kritik ist: sie tun es nicht!

Zitat:

Aber ein schlechter Kompromiss, genausogut könnte man die VCL erweitern und Wrapper um die X Window API machen und eventl. noch Window Manager berücksichtigen. Ein ordentlicher Pascal-Wrapper dafür wäre durchaus machbar und von allen verwendbar (wodurch sich die Last verteilt) aber eben nicht auf GTK basiert.

Zitat:

Du hast nie ein reines X-Programm gesehen, oder?

Ich habe sogar schon eines programmiert. Und X bietet auch Fensterchen, Menüs und Nachrichten, Maus, ... bietet zwar nicht soviel wie Windows und keine Datei-Dialoge aber darum soll sich ja GTK und co kümmern, aber nicht einfach alles selbst machen. Wiederverwenden was da ist.

Zitat:

Unsinn, nur Win32 API und X Window API, der Window Manager(für Unix) macht kaum mehr als die Darstellung. Um die Abweichungen muß sich außerdem GTK auch kümmern, und das tut es auch nicht immer so schön.

Zitat:

Du hast tatsächlich nie ein X-Programm gesehen

Und Du noch nie was von einem anständigen Gespräch gehört, ich maße mir nicht an über Dich zu urteilen.

Zitat:

Wenn du optisch auf das Niveau von Windows kommen willst, hast du schon fast ein fertiges TK, da kannst du auch ein fertiges (GTK, Qt, ...) nehmen.

Nicht optisch, sondern von der Komplexität der Steuerelemente her.

Zitat:

Zitat:

Stöhn nicht, es geht darum das Windows Software wie Windows Software funktionieren und aussehen muß, gleiches gilt für Linux Software und für Crossplattform.

Windows-Software sieht i.A. wie Windows-Software aus. Linux-Feeling kriegst du nur, wenn du Software, die für Linux entwickelt wurde, nach Windows rüberschleppst.

Falsch, alle Crossplattform Programme sehen so aus, und das ist unakzeptabel.

Zitat:

Schön, wenn du 300 Sprachen kannst, einige Programmierer beschäftigen sich aber mehr mit den Programmfeatures und mit den Bugfixes als mit Oberflächenpolierung auf Systemen, die sie nur aus Gefälligkeit unterstützen, weil die Nachfrage für einen Windows-Port so groß war.

Warum schreibt man denn Programme? Damit sie von jemanden genutzt werden können, und nicht um zu sagen "ich bin so toll, warum gefällt Dir Trottel nicht wie mein Programm funktioniert".
GUI Design ist sehr wichtig, es geht ja nicht um kleine Zeichenfehler, sondern das jedes Programm anders funktioniert und dafür gibt es BSe. Verwendet man Bordmittel beherrscht man ein Programm im Handumdrehen, sonst ist dauerend Einarbeitung nötig = unproduktiv.

Zitat:

Ja, mit einem heidenaufwand. An der Native Widget Unterstützung für OpenOffice.org2 hat man über ein Jahr rumentwickelt. Zeit, die man bei kleineren Projekten mit wneiger Entwicklern besser in das Programm selbst stecken sollte.

Ist doch gut das sie sich die Mühe machen. In Zukunft kann man dann auf dieser Arbeit aufbauen. (Du scheinst immer noch nicht zu verstehen, daß ich nicht verlange, daß jeder alles nochmal neu macht, aber das es ein gutes Framework geben muß.)

Zitat:

Ganz ehrlich, ohne dir nahetreten zu wollen, mir scheint, als hättest du dir vieles nicht genau angesehen.

So ein Kommentar kommt immer wenn die Argumente ausgehen

Zitat von mael:

Meinungen über die Produktivität einer IDE sind immer subjektiv. Es gibt auch Leute, die lieben Lazarus.

Schön das Du auch mal endlich merkst das nicht deine Sicht die Wahrheit ist.

[tommie-lie]

Zitat von mael:

Zitat:

Und ganz ehrlich: ich verwende lieber die String-Funktionen der libc als die der FPC-RTL...

Wenn das so ist, solltest Du sowieso FP sein lassen.

Welche andere Pascal-Implementierung soll ich denn unter Linux sonst benutzen? GPC, das nicht DelphiLanguage-kompatibel ist, weil es sich an die offenen Standards hält? Oder Kylix, dessen IDE auch nicht wesentlich besser ist und das unter einem 2.6er-Kernel nicht mehr zuverlässig läuft und mittlerweile auch veraltete Units hat?

Zitat:

System V IPC Sachen sind in Kylix libc.pas definiert, JEDI hat, bis jetzt, soweit ich weiß dafür keine Unterstützung.

Ist ja eigentlich auch nicht deren Aufgabe. Als Joint Endeavor of Delphi Innovators brauchen sie sich eignetlich nicht um IPC von anderen Betriebssystemen kümmern.

Zitat:

Die pthread.h ist aber kurz und schnell übersetzt, also kein wirkliches Hindernis. Wie wäre es: Übersetzte es und schick es auf die JEDI mailing Liste.

Wie wäre es: Ich benutze einfach die Standardbibliothek für sowas, die GNU C Library?

Zitat:

Zitat:

Qt

Wird nicht korrekt gezeichnet, die Menüs wackeln hin und her, die Shortcuts sind schlecht implementiert, Teile werden nicht gezeichnet (z.B. beim PageControl)

Ist mir in meinem (zugegebenermaßen kurzen) KDE-Leben nicht aufgefallen. Zumindest hat Gnome/GTK derartige Probleme nicht, und auch die Menüs von Knoppix oder Kanotix wackeln nicht hin und her. Um schlechte Erfahrungen mit Shortcuts zu machen hatte ich es nie lange genug in produktivem Einsatz, in Gnome funktionieren sie aber.

Zitat:

Du ignorierst einfach was ich sage. Es geht nicht was für Programme ich verwenden will, es geht darum das GTK sich nicht an Windows hält

Gtk ist auch nicht für Windows gemacht!
Schau mal, geh mal auf www.gtk.org. Im dortigen Download-bereich findest du eh nur die Quellen. Das "GTK+ for Win32"-Projekt ist nichtmal auf gtk.org gehostet, es ist Teil des GIMP-Projekts und nichtmal davon ein offizieller Teil. Es wird von Tor Lillqvist maintained und mehr oder weniger eine private Entwicklung. Und wenn du den Windows-Links auf [url}www.gimp.org[/url] folgst, wirst du sogar merken, daß der Windows-Port ein eigenständiges Sourceforge-Projekt ist, nämlich gimp-win.

Zitat:

Außerdem werden häufig auch Programme von Windows nach Linux portiert.

Was ohne wine(lib) ein unglaublicher Aufwand ist, weil kein einziger der Calls auch nur ansatzweise unter Linux existieren.

Diese ganze Diskussion lässt sich ganz einfach komprimieren: GTK hatte never ever das Ziel, Windows zu unterstützen, und dennoch bist du der Meinunng, daß es deren Aufgabe sei, native Dialoge des jeweiligen Systems zu verwenden. Für sowas war aber GTK nie gemacht worden.

Zitat:

Lies richtig, es geht um die Frameworks. Die sollen sich nach dem Standard richten, wenn sie das tun, mußt DU Dich nicht um die Details kümmern. Die Kritik ist: sie tun es nicht!

"Ich" war in diesem Fall jemand, der irgendwas auf allen Plattformen zugänglich machen will. Das sind auch die Trolltech- und GTK-Leute. Es ist und bleibt das gleiche Problem: Eine Heidenarbeit, für die niemand Zeit hat.

Zitat:

Ich habe sogar schon eines programmiert. Und X bietet auch Fensterchen, Menüs und Nachrichten, Maus, ...

Ich weiß, was es kann, aber es sieht hässlich aus, wenn man nicht erheblich mehr Arbeit in die Oberfläche steckt als in die Programmlogik.

Zitat:

Zitat:

Wenn du optisch auf das Niveau von Windows kommen willst, hast du schon fast ein fertiges TK, da kannst du auch ein fertiges (GTK, Qt, ...) nehmen.

Nicht optisch, sondern von der Komplexität der Steuerelemente her.

Wenn du Gnome oder KDE benutzt, integriert sich ein X-Programm überhaupt nicht in die bestehende Oberfläche. Ist dir das wirklich lieber als zwei verschiedene Dateidialoge?

Zitat:

Falsch, alle Crossplattform Programme sehen so aus, und das ist unakzeptabel.

Ja, das ist es, was ich sagte. Linux-Programme sehen meist wie Linux-Programme aus, und mit Windows-Programmen sieht's genauso aus. Erst was rübergeschleppt wird muss sich irgendwo in der Mitte treffen. Crossplatform-Anwendungen, die auf jeder Zielplattform wie zuhause aussehen sollen, sind keine plattformübergreifenden Anwendungen mehr, sondern Ports der kompletten GUI auf die jeweilige Zielplattform. Ein komplettes Rwrite kommt dem ganzen noch am nächsten, auch wenn man wenigstens die ganzen Backends mitbenutzen kann, wenn die Entwickler nicht gepennt haben und Backend und Frontend so miteinander verflochten haben, daß man trotzdem den kompletten Code neuschreiben darf.

Zitat:

Warum schreibt man denn Programme? Damit sie von jemanden genutzt werden können, und nicht um zu sagen "ich bin so toll, warum gefällt Dir Trottel nicht wie mein Programm funktioniert".
GUI Design ist sehr wichtig, es geht ja nicht um kleine Zeichenfehler, sondern das jedes Programm anders funktioniert und dafür gibt es BSe. Verwendet man Bordmittel beherrscht man ein Programm im Handumdrehen, sonst ist dauerend Einarbeitung nötig = unproduktiv.

ACK.
Aber wenn ich auf mehreren Hochzeiten feiern will, müsste ich für jedes Betriebssystem eine eigene Oberfläche entwickeln und maintainen. Da ich persönlich mich lieber auf die Funktionalität des Programmes konzentriere und nicht 80% meiner Arbeit in die Oberfläche stecke, nehme ich da lieber etwas, was auf allen Plattformen verfügbar ist und portiere nicht jeden Dialog rüber.
Echt Plattformunabhängigkeit gibt es bereits mit Java, dort sehen alle Programme gleich (schlecht ) aus. Und wenn ich mich nicht irre gibt es sogar für Java entsprechende Schnittstellen zum unterliegenden System, sprich native widgets.

Zitat:

Ist doch gut das sie sich die Mühe machen.

Finde ich nicht. Sie könnten schon Version 2.0 fertig haben, wenn all jene, die an den native widgets gearbeitet haben, an der Anwendung selbst entwickelt hätten.

Zitat:

(Du scheinst immer noch nicht zu verstehen, daß ich nicht verlange, daß jeder alles nochmal neu macht, aber das es ein gutes Framework geben muß.)

Du bist Programmierer, du kannst gerne anfangen. Es gibt sicherlich Leute, die sich die Finger nach sowas lecken werden. Die großen Linux-Projekte à la GIMP oder Openoffice.org werden es aber nicht sein.

[Robert_G]

OT:
Ist immer wieder lustig, wenn tommie einen zum rumsticheln gefunden hat.
*sich wieder schmunzelnd zurückzieht*

[Hansa]

Tja, es ist immer wieder lustig wie manche mit Fachbegriffen um sich schmeißen, die sie irgendwo gehört haben aber das ganze eigentlich gar nicht benutzen. 8)

Da der Thread nun mit der Ausgangsfrage überhaupt nichts mehr zu tun hat, sondern eher mit Linux / Windows : es hieß, ein Windows - Programm solle aussehen wie ein Windows - Programm und nicht wie ein Linux Programm usw. Wenn dem nicht so ist, dann nervt das IMHO die Enduser. Gestern wollte ich z.B. was aus dem Internet ausdrucken. Hellblaue Schrift auf Schwarz. Echt cool. 8) Ich habe einen Teil des Textes nach Word kopiert. Da war das coole dann eben, daß die hellblaue Schrift auf dem weißen Papier gar nicht zu lesen war. Ich mußte die Schriftfarbe also erst auf schwarz umstellen um es dann drucken zu können.

Das Problem bei "Standards" ist nun leider, daß es zumindest bei Windows keiner ist ! Wer sich strikt an die Mickysoft "Standards" hält, der bekommt massive Probleme sein Programm nach ISO???? zertifizieren zu lassen. Denen (und auch mir) ist es u.a. nämlich ein Greuel, mit ALT-F4 ein Fenster schließen zu müssen und mit TAB zum nächsten Steuerelemet zu gehen. Wer hat sowas erfunden ?

Wie gesagt, es geht dabei nicht mal so um das Aussehen, sondern um eine einheitliche, intuitive Bedienung eines Programmes ohne Verrenkungen im Handgelenk. Es wäre wohl schon wichtiger, sich über solche Sachen mal Gedanken zu machen, als über Betriebssysteme oder auch C zu diskutieren, die man sowieso nicht beeinflussen kann.

[MathiasSimmack]

Zitat von Hansa:

Gestern wollte ich z.B. was aus dem Internet ausdrucken. Hellblaue Schrift auf Schwarz. Echt cool. 8)

Da sah im Web sicher auch gut aus.

Zitat:

Ich habe einen Teil des Textes nach Word kopiert.

Ich hätte ganz einfach im Browser eingestellt, dass selbiger nicht mehr die Styles der Seite sondern meine Standardfarben benutzt. So was können gute Browser. Dann hättest du gleich drucken können.

[Mephistopheles]

Code:

M = M * V;

Dies ist das Kreuzprodukt mit einer Matrix und einem Vektor.

Code:

us1 += us2;

Code:

us1 += L"\blablubb";

Code:

us1 += "Ein ANSI-String ... blabla";

Dies war eine Wrapperklasse für die UNICODE_STRING-Struktur in Aktion.
Ich komme dann wieder sobald operator-Überladen in Delphi auch geht (ohne .NET!)

Noch Fragen?

... ihr wißt ja: ich bin der Geist, der stets verneint

And the winner is ... Celphi++

[mael]

Zitat von Hansa:

Das Problem bei "Standards" ist nun leider, daß es zumindest bei Windows keiner ist ! Wer sich strikt an die Mickysoft "Standards" hält, der bekommt massive Probleme sein Programm nach ISO???? zertifizieren zu lassen. Denen (und auch mir) ist es u.a. nämlich ein Greuel, mit ALT-F4 ein Fenster schließen zu müssen und mit TAB zum nächsten Steuerelemet zu gehen. Wer hat sowas erfunden ?

Wie gesagt, es geht dabei nicht mal so um das Aussehen, sondern um eine einheitliche, intuitive Bedienung eines Programmes ohne Verrenkungen im Handgelenk. Es wäre wohl schon wichtiger, sich über solche Sachen mal Gedanken zu machen, als über Betriebssysteme oder auch C zu diskutieren, die man sowieso nicht beeinflussen kann.

Solche Sachen wie man ein Fenster schliesst lassen sich z.B. elegant loesen wenn man wie KDE diese Tastenkuerzel konfigurierbar macht. Daher ist es also wichtig das BS + WindowManger zu achten um Komfort fuer den Benutzer zu erreichen, also auch spezielle Features des BS zu unterstuetzen.

Was Windows angeht, ist bestimmt nicht alles perfekt, aber es sind wohl die meistens Nutzer daran gewoehnt. Jetzt mal einfach sein eingenes Design/Konzept aufzuzwingen kann es wohl nicht sein. Und wenn schon, dann muss man es auf jeden Fall auf den BS Standard umstellen koennen.

ALT+F4 ist fuer mich kein Problem, Klavierspielen macht die Haende sehr flexibel

[mael]

Zitat von Mephistopheles:

Code:

M = M * V;

Dies ist das Kreuzprodukt mit einer Matrix und einem Vektor.

Code:

us1 += us2;

Code:

us1 += L"\blablubb";

Code:

us1 += "Ein ANSI-String ... blabla";

Dies war eine Wrapperklasse für die UNICODE_STRING-Struktur in Aktion.
Ich komme dann wieder sobald operator-Überladen in Delphi auch geht (ohne .NET!)

And the winner is ... Celphi++

Freepascal hat Operatorueberladung, aber wie schon gesagt, bei Delphi fehlt die Weiterentwicklung der Sprache.

Was die Unicode-Sache angeht, es gibt WideString, was also soll das Beispiel?

[tommie-lie]

Zitat von mael:

Was die Unicode-Sache angeht, es gibt WideString, was also soll das Beispiel?

Hihi, die RTL ist aber nicht sonderlich darauf ausgelegt, und auch die VCL-Controls unterstützen es nicht. Du bist also auf Fremdkomponenten angewiesen, wenn du deine Controls nicht zu Fuß über die API mit Daten versorgen willst.

Zitat von mael:

elegant loesen wenn man wie KDE diese Tastenkuerzel konfigurierbar macht.

Kann Gnome auch.