wp_xyz hat geschrieben:
Auch wenn diese Diskussion einige nervt, ich habe dabei viel gelernt.
Also "einige" nervt er bestimmt nicht, du meinst wohl mich? Nicht mal mich nervt dieser Thread.
Es ist einfach so, dass ich wahrscheinlich für mich schon etwas früher die Einordnung dieses Problems zu "Nebenschauplatz", "aufwändig und wenig nutzbringend" gemacht habe. Mittlerweile dämmert das auch dem OP, und das finde ich gut.
Was nicht heisst, dass ich die sachliche Kritik nicht anerkenne. Nur hat das "Problem" hat für mich eine vernachlässigbare Priorität, welche in etwa der Behandlung von Bug Eintrag 0009366 entspricht.
Der OP hat in diesem Thread den Weg zurückgelegt vom Anwender, der erst mal an sich selbst zweifelt (siehe Thread - Titel) über den, der sich darüber ärgert, dass ein Verhalten, das eine Komponente zeigen sollte, nicht da ist (was ihn ausbremst), zu dem, der dann nachforscht, was eigentlich los ist, und schließlich die Erkenntnis gewinnt, dass die Implementierung der fehlenden Funktion nicht trivial ist, und ein gewisses Verständnis für den Autor von TTextString äußert. Soviel zum "dämmern". Theo, direkte Frage: Stammt TTextString von Dir?
Ich stimme allerdings Michael zu, Es wäre sinnvoll, wenn die Objekte in TMemo.Lines funktionieren würden. Einfach deshalb, weil die Deklaration von TStrings einen dieses erwarten lässt. wenn das nicht geht (mit vertretbarem Aufwand und/oder Nebenwirkungen), dann gehört es dokumentiert, und der Versuch, Objekte zuzuweisen, per Exception abgefangen. Alles andere baut dem Anwender genau die Falle, in die ich ahnungslos reingetappt bin. Dass es Quatsch ist, die Lines von TStrings abzuleiten (und schon in Delphi - 2? 3? sicher 4) Quatsch war, steht auf einem anderen Blatt. Saubere Objekthierarchie wäre eine Vorgängerklasse von TStrings ohne Objekte, aber das schmeißt dann tatsächlich die ganze Kompatibilität über den Haufen.
Ich unterstelle übrigends mit "Falle" niemandem böse Absichten. Auf schwäbisch heißt sowas "dumm gloffa".
Es passt nicht zur Funktion eines Editors mit den erwähnten Features.
Ausserdem habe ich eine dumpfe Ahnung, wo der Inhalt tatsächlich gespeichert wird, und das ist wohl in den entsprechenden Widgetset Controls. Dass diese sich direkt auf die gesamte Funktionalität von TStrings mappen lassen ist eher unwahrscheinlich.
ghieber hat geschrieben: zeichenweisen editiererei von TMemo, auch über Zeilengrenzen hinweg,
OK. Das ist einsichtig. Es entstehen also "om the fly" neue Zeilen. Und durch den automatischen Umbruch rutscht der Text von eine4r Zeile in eine andere.
Fazit: Es ist vielleicht nicht schwierig irgendetwas zu implementieren, es gibt aber vermutlich keinen Idee davon, welche Funktionalität man sich sinnvoller Weise wünschen würde.
Also sollte - wie ober geschrieben - jeder Zugriff auf die Objects Property zu einer Exception führen.
Das Ter Text durch den automatischen Umbruch verrutscht, ist nicht das Thema, "lines" sind hier nicht sichtbare Zeilen, sondern durch explizite Zeilenende - Marker getrennte Absätze. Das Problem ist, dass die ganze editiererei, incl. cut an paste etc. in einem im Widgetset implementieren Buffer stattfindet, und die Lines - Property da nur "drangepappt" ist.
Michael, schau Dir den Quelltext von TTextStrings an. Das sieht wirklich so aus, als hätte der Autor vorgehabt, die Objekte zu implementieren, an vielen Stellen ist hier nämlich sinnvolle Funktion da. Scheitern tut's daran, dass die Änderungen im Text nicht mit dem Array synchronisiert werden (können?) und deshalb das Array einfach neui aufgebaut wird, wenn die Synchronisation verloren geht. Dabei fallen die Objekte unter den Tisch. Vielleicht liest der Autor (oder jemand, der damals beteiligt war) hier ja mit, und kann ein paar Worte dazu sagen. Mir geht's hier inzwischen primär um Erkenntnisgewinn...
@ghieber: Das sage ich doch eigentlich schon die ganze Zeit, dazu brauche ich TTextStrings nicht einmal anschauen.
Wo erwartest du weiteren Erkenntnisgewinn?