Innere Struktur von TStrings / TMemo

[jaenicke]

Zitat von Popov:

Ich weiß nicht wo ich den Hinweis gelesen habe, ob im Code oder der Hilfe, auf jeden Fall stand dort, das bei TMemo TStrings nicht so arbeitet wie es eigentlich tun sollte.

Doch, TMemoStrings arbeitet schon genau so wie es das tun soll. Nur ist es eben nicht dafür gedacht zu etwas anderes als zur Anzeige oder Benutzereingabe zu dienen wie ja richtigerweise auch schon im Eingangspost steht.

[Dejan Vu]

Zitat von jaenicke:

Nur ist es eben nicht dafür gedacht zu etwas anderes als zur Anzeige oder Benutzereingabe zu dienen wie ja richtigerweise auch schon im Eingangspost steht.

Wenn Du mal einen 'Zeilenumbruch' anhand von Buchstabenbreiten implementieren willst, dann ist ein TMemo offensichtlich genau das Richtige.

[Popov]

Zitat von jaenicke:

Doch, TMemoStrings arbeitet schon genau so wie es das tun soll. Nur ist es eben nicht dafür gedacht zu etwas anderes als zur Anzeige oder Benutzereingabe zu dienen wie ja richtigerweise auch schon im Eingangspost steht.

Mit "das bei TMemo TStrings nicht so arbeitet wie es eigentlich tun sollte." meinte ich nicht, dass TStrings in TMemo unberechenbar ist und sonderbar arbeitet, sondern, dass es nicht 100% die Eigenschaft hat die es haben müsste. Beispiel: Lines von TMemo ist TStrings. TStrings kann Objekte fassen, Lines nicht. Obwohl es TStrings ist. Das meinte ich u. a. mit: "wie es eigentlich tun sollte".

Wenn man eine Klasse kennt, dann erwartet man immer gleiches Verhalten. Hier ist es nicht der Fall.

[himitsu]

Es verhällt sich alles genau so, wie es soll.

Bezüglich der Zeilenumbrüche funktioniert alles vollkommen richtig, genau so wie es die Definition der Komponente besagt.

TStrings bietet die Möglichkeit Objekte zu speichern, aber es muß nicht implementiert sein.
Gut, ich empfinde es schon immer als Fehler, daß der Objects-Setter von TMemoStrings keine Exceptions wirft, aber auf mich hört ja keiner.
Und nein, da MEMO es nicht anbietet, daß Zeilenbasiert Informationen gespeichert werden können, kann auch Lines dieses Feature nicht anbieten.
Bei TStringList und dn Items einer TListBox ist das was Anderes, denn dort besitzen die Komponenten einen Speicher dafür.

[Popov]

Sonderbar, im ersten Post steht etwas über Probleme, aber kaum geht man drauf ein, schon behaupten alle, dass alles so ist wie es sein soll. Wozu dann die Frage?

Natürlich ist es so wie es sein soll. Deshalb auch der Hinweis in der Hilfe. Hat zwar jetzt nichts mit dem Thema zu tun, aber mit TStrings:

Zitat:

Hinweis: Obwohl die Eigenschaft Lines von TStrings abgeleitet ist, implementiert sie keine Unterstützung für das Zuordnen von Objekten zu den Listen-Strings.

Hinweise sind ja auch dazu da übliches Unübliches üblich zu machen.

[Sir Rufo]

Wie sollte denn das Speichern von Objekten bei einem Memo funktionieren?

Richtig, es ist nicht sinnvoll implementierbar ... darum hat man es sich verkniffen irgendeinen Quatsch zu implementieren.

Falls jemand da aber eine zündende Idee hat, immer her damit.

[himitsu]

Zitat von Sir Rufo:

Falls jemand da aber eine zündende Idee hat, immer her damit.

Eine Exception beim Zuweisen, damit man sofort mitbekommt, daß der Zuweisung ins Nichts ging.

Einfach so nichts zu machen ist jedenfalls nicht die beste Lösung.

[jaenicke]

Zitat von Sir Rufo:

Wie sollte denn das Speichern von Objekten bei einem Memo funktionieren?

Richtig, es ist nicht sinnvoll implementierbar ...

So allgemein stimmt das nicht, man muss nur neu hinzugefügte Zeilenumbrüche tracken usw., nur dass ich das eben manuell mache. In meinem Fall füge ich Inhalte von mehreren Dateien in einem Editor zusammen und markiere die Herkunft farblich. (Es handelt sich um eine spezielle Skriptsprache.)
Wenn nun eine neue Zeile hinzugefügt wird, wird das Tracking entsprechend hinzugefügt, zu welcher realen Datei diese Zeile dann gehören wird. (Zu der Datei, in dessen Zeile Enter gedrückt wurde.)
Und am Ende wird dann alles in die einzelnen Dateien wieder gespeichert.

Dieses Tracking gibt es bei Syntaxeditoren ja auch.

Dass der Aufwand für TMemo als allgemeiner Komponente nicht sinnvoll gewesen wäre, sehe ich aber auch so. Möglich wäre es durchaus gewesen.

[Popov]

Zitat von Sir Rufo:

Wie sollte denn das Speichern von Objekten bei einem Memo funktionieren?

Richtig, es ist nicht sinnvoll implementierbar ... darum hat man es sich verkniffen irgendeinen Quatsch zu implementieren.

Falls jemand da aber eine zündende Idee hat, immer her damit.

Zuerst, ich gebe dir zuerst mal Recht (unabhängig dessen was jaenicke geschrieben hat, das ist aber ein anderes Thema).

Auf der anderen Seite, und da muss ich mal zugeben, dass ich mich inzwischen selbst bisschen blöd vorkomme, stellt sich mir die Frage wieso wir darüber überhaupt diskutieren? Ich mache mal ein Beispiel: User1 sagt: "Der Smart ist ein schönes Auto, man kann damit wunderbar in der Stadt fahren und findet leicht Parkplätze. Hat aber wenig PS." Darauf antwortet User2: "In der Stadt braucht man auch nicht viel PS." Woraus User3 antwortet: "Wieso sollte man den Smart in der Landwirtschaft als Tragtorersatz einsetzten. Dafür fehlen ihm die PS und das Gewicht und die Räder." Darauf erwidert User2: "Der Smart ist auch ein Stadtauto." Wozu User3 wieder sagt: "Es ist absolut unsinnig den Smart als Traktor zu nehmen. Dafür ist er absolut ungeeignet."

Sonderbarerweisen hat niemand unrecht, aber warum redet man plötzlich über Traktoren?