Ich finde ein einfaches Memo zu schreiben inzwischen gar nicht mehr zu schwierig.

Aber sowas wie ein RTF Editor zu schreiben finde ich um so scherer. Ich habe mir mal einige Beiträge hier im Thread dazu durch gelesen.

Ich habe mal mit einem über PM gesprochen, der hat eine eigene RTF Editor Komponenten geschrieben für Delphi. Ohne auf DLLS zurück zu greifen.
Er hat mir auch das Prinzip erklärt. Das klang eigentlich recht einfach
Die Objekte wurden in einer TObjectList gepeichert.

Beim Scrollen z.b. hat er immer die Text Position neu bestimmt/Berechnet.
Beim umsetzten ergaben sich jedoch einige Probleme. Aber das Prinzip fand ich nicht schlecht.
Jede Zeile wurde durch ein NewLine Variable gekennzeichnet.
Allerdings war das Markieren mit Aufwand verbunden.

Er hat jede andere Formatierung als neues Objekt gespeichert. All diese Objekt haben über ein SelStart und ein SelEdn verfügt(vom typ TPoint)
Das markieren habe ich auch nicht ganz verstanden. Geschweige denn das Scrollen.

Ich habe mal vor einigen Monaten ein anderes Konzept verfolgt, aber leider noch nicht fertig gestellt:

Ich habe mir eine eigene Scroll Box erstellt, die auch nur meine Objekte verwalten konnte.
Darunter waren Objekte für das Anzeigen von einfachen Texten, und von Bildern. Es ist auch möglich Scrollbereiche zu verschachteln.

Es gibt zwar noch einige kleine CPU-Probleme. Aber sonst geht das Prinzip. Dieses Konzept wollte ich eigentlich nutzten, für mein Nachfolger von PLEditor.
Der soll dann schon mehr RTF ähnlich sehen, als Synedit.
Ich habe mir auch eine eigene Klasse erstellt die TStingList sehr nahe kommt, aber mehr kann bzw. mehr Daten Speichert pro Buchstabe. Dort ist jeder Buchstabe ein Objekt. Das kann später noch optimiert werden.

Die Idee ist jetzt einfach: ich erzeuge ein Text Fehld, wo ich halt ein Text bearbeiten kann, und davon kann ich mehrer Fehler innerhabl der Scrollbox erzeugen, wobei das Text fehld ebenfalls von der Scrollbox abgeleitet ist um halt a) außerhalb der Scrollbox zu Funktionieren b) um ein eigenen Scroll Bereich zu schaffen.

Wenn ihr wollte kann ich das Projekt mal hochladen. Das was es bisher schon gibt.


// Lossy: Abgeschnitten von Meinungsthread glPasGUI

_________________
MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus

Hallo Pluto.
Bin jetzt nur mehr sporadisch hier, daher antworte ich nicht immer gleich.


Genau das ist es. Es nutzt nichts, ein noch so geniales Konzept zu entwickeln, wenn man es nicht umsetzen kann. Das einzige Kriterium ist daher, dass man das Ding nachher benutzen kann. Wozu macht man sich sonst die Mühe?


Das würde ich an Deiner Stelle nochmal überdenken. Dass man jeden Buchstaben mit eigenen Eigenschaften belegen kann (fett, unterstrichen etc.) muss nicht unbedingt bedeuten, dass auch jeder Buchstabe ein eigenes Objekt sein muss. Das könnte die Bearbeitung so aufblähen, dass die Schnelligkeit der Anzeige darunter leidet: man kann bei der Datenstrukturierung auch des Guten zuviel tun. Es würde doch auch so gehen: ich habe Daten (den Text eines Absatzes zum Beispiel) und zugehörige Steuerdaten (die Formatierung mit Positionsangaben). Diese Dinge sollte man jedenfalls schneller verknüpfen und anzeigen können, als jeden Buchstaben einzeln zu behandeln.


Vorsicht: das spätere Optimieren eines solchen Konzeptes könnte bedeuten, dass man es wegwerfen und alles neu machen muss.

Viele Grüße
Traude

wie genau meinst du das ?

Ich dachte eher an sowas:
Jeder Buchstabe speichert nur die wichtigensten Daten wie halt x und y Position sowie die Größe evlt.
Dann hat er einen Pointer auf einer Liste wo das Aussehen gespeichert wird.
Nachteil ist halt beim hinzufügen bzw. ändern vom Aussehen z.b. das dann halt zuerst in dieser Liste geschaut werden muss ob es diesen Style schon gibt oder nicht. Aber sonst dürfte das meiner Meinung nach speicher Sparen bei größeren Dokumenten.

IM DP meinter einer, ich sollte eine art Baumstruktur verwenden. Allerdings bin ich bis heute nicht dahinter gekommen wie er das gemeint hat, und auf meine frage hat er auch nicht geantwortet.

Als Baum kann ich mir sowas beim besten willen nicht vorstellen. Dann schon ehrer als eine "Doppelt Verkette Liste".
So eine Klasse hatte ich mal erstellt und wollte sie auch eigentlich nutzten für das Konzept....

_________________
MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus

Was die Klassen angeht kann ich Traude nur vollkommen zustimmen. Also eine Klasse aus jedem Zeichen zu machen wäre wohl zu viel des Guten. Was du nicht vergessen darfst. Klassen haben einen overhead was Speicher angeht und erstellen freigeben von 100.000 Instanzen dauert. Genau so sehe ich das auch mit dem X/Y Koordinaten pro Zeichen. Die Zeichen sollten nicht frei schwebend sein sondern schon noch irgendwie zusammengehören. Zu mal du mit den meisten APIs Text auch besser Blockweise ausgeben kannst als Buchstabenweise. Und das sollte man dann auch nutzen.

Ich persönlich würde es vermutlich so machen, dass ich verschiede Objekttypen in einer Liste ablegen würde. Diese Typen wären dann unter anderem so etwas wie WORD, SPACE, FORMAT. WORD enthält also einen Text. SPACE enthält einen oder mehrere Leerzeichen, damit man den Text umbrechen kann. FORMAT würde dann eine Formatbeschreibung enthalten. Diese Formatbeschreibungen würden sich dann auf alle nachfolgendes Textbestandteile übertragen. So lange bis sie wieder überschrieben werden. Denn der Vorteil besteht darin, dass du nicht bei jedem Zeichen suchen musst welches Format es hat sondern du einfach nur ein Format hast was zwischendurch aktualisiert wird. Also brauchst du dich nur darauf zu konzentrieren den Text zu verarbeiten. So lange bis eine neue Formatbeschreibung eintrifft und dann nimmst du ab dann diese. Ich meine auch, dass das RTF Format auch so in etwa aufgebaut sein müsste. Bzw verwende ich genau so etwas auch in meiner Text Bibliothek.

Wenn du eine Textpassage dann formatieren wolltest müsstest du nur am Anfang des Blockes ein FORMAT einbringen (Text ist eine einfach verkettete Liste) und anschließend am Ende des Blockes das vorher Gültige. Zum Zurücksetzen.

Was den Baum angeht. Ich denke das wäre etwas ähnliches wie das was ich vorgeschlagen habe nur eben in Richtung Baum gezogen. Das würde das Hinzufügen einer Formatierung in der Verwaltung vereinfachen. Dann würdest du nämlich den Block ausschneiden und anstelle des Blockes ein FORMAT einbringen. Unterhalb des Formates würdest du dann den Block einbringen. Beim Rendern müsstest du dann durch den Text und bei FORMAT dann eine Ebene tiefer gehen. Dann hättest du eher so etwas wie einen Stack. Aber was wäre, wenn du von der Mitte des Blockes bis 2 Wörter hinter dem Ende des Blockes etwas anders formatieren wolltest. Also sofern die Formatierung Addaptiv wäre (Stilformatierung). Dann müsstest du hergehen und alles was hinter dem Block wäre noch mal in einem extra FORMAT packen.

Was die Verwaltung angeht ziehe ich dann eher eine normale Liste vor. Dann brauch ich bloß Elemente irgendwo dazwischen setzen oder entfernen. Überlappende Bereiche von Formatierungen wären so gar kein Problem. Allerdings muss man darauf achten, dass man die Elemente passend setzt. Also immer zwei. Und solltest so etwas wie das Style Bold auf einen Bereich angewendet werden der bereits Bold enthält, dann musst man die beiden Bereich zu einem Bereich zusammenfassen. Aber bei einem Baum hätte man dieses Problem auch. Evtl sogar noch schlimmer.

Ich meine das so: jedes Objekt hat intern einen gewissen Overhead, weil es natürlich auch verwaltet werden muss. Pro Buchstabe ein Objekt anzulegen hätte ich mir nie überlegt. Nur mal überschlagen: durchschnittlich 80 Zeichen in einer Zeile, 50 Zeilen in einer Seite, und sagen wir mal 20 Seiten: das wären dann 80.000 Objekte (in Worten: achtzigtausend). Ein 20-Seiten-Dokument ist aber gar nicht besonders lang; Du müsstest also auch mit erheblich mehr rechnen.

Es ist auch nicht notwendig, jeden einzelnen Buchstaben mit einer Position zu versehen. Dann musst Du doch bei Änderungen alle nachfolgenden umpositionieren. Im obigen Beispiel im Durchschnitt 40.000 mal bei jeder Änderung.(!)


Aber hier:

bin ich voll und ganz Deiner Meinung. Ich kann bei einem Text auch keine Baumstruktur erkennen. Ein Datenverzeichnis/Inhaltsverzeichnis hat eine Baumstruktur, eine GUI hat eine Baumstruktur (:wink:), geschachtetele Abfragen haben eine Baumstruktur, aber Text hab ich immer als einen fortlaufenen Strom von Buchstaben verstanden.

@Doppelt verkettete Liste: ein kleiner Tip: Du brauchst für ein Textverarbeitungsprogramm jedenfalls die Möglichkeit, jede Textposition in möglichst kurzer Zeit erreichen zu können. Der Benutzer kann das ja schließlich auch: er kann im Extremfall vom Textanfang zum Textende springen. Daher musst Du Dir so eine Möglichkeit auch offenhalten. Wenn Du das mit der doppelt verketteten Liste schaffst, dann ist es OK.

Traude


EDIT: Lossy war schneller

>Es ist auch nicht notwendig, jeden einzelnen Buchstaben mit einer Position zu versehen.
es vereinfacht vieles. Z.B. Das Klicken mit der Maus.

Was den overhead angeht, da habe ihr natürlich recht. Darum habe ich mir noch keine Gedanken gemacht.

Ich weiß das Doppelt verkettete Liste ihr nach unter Vorteile habe z.b. ist das Einfügen/Löschen relativ schnell, aber das Auslesen von bestimmten Einträgen dauert länger, weil das erst durch eine while schleife bestimmt werden muss.

Lossy eX, deine Idee gefällt mir eigentlich recht gut, so wollte ich das auch machen.
Nehmen wir mal ein kleines Beispiel:

Ich habe ein Satzt: (fg:red)Roter Text(/fg) Hallo wie geht es dir so ? (bg:blue)Hallo(//bg)
Ich hoffe ihr wisst wie ich mir das vorstelle.

Nehmen wir an, ich verwalte alles in einer Object Liste, und zwar nicht Buchstabenweise sondern Objekt weise.
z.b. währe "Roter Text" das erste Objekt das zweite währe "Hallo wie geht es dir so ?" und das dritte währe dann "Hallo"
jeweils in ihrer gewünschten Formatierung. Im Prinzip kein Problem.

Was passiert jetzt aber, wenn ich einen Text Markieren möchte ? In meinen Fall hätte jetzt jedes Objekt, zwei Variablen: SelStart, SelEnd von Typ TPoint. Wenn ich jetzt die Formatierung Ändern möchte müsste ich das Objekt spliten sehe ich das richtig ?
ach ja und jede Zeile ist durch ein NewLine gekenzeichnet.

Wenn ich den Namen vom Autor, wieder findet der die Native RTF Edit Komponente geschrieben habe, werde ich hier den link posten. Da war auch ein Soruce-Code dabei. Ich habe ihn sogar versucht anzupassen, allerdings nach einiger Zeit aufgeben.

Was haltet ihr von dem Vorschlag es gemeinsam zu versuchen ?
Entweder eine eigene Komponente zu schreiben, oder die anzupassen. Sowas habe ich schon lange vor. In gewisserweise tun wir das auch schon. *G*

_________________
MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus

Kommt gar nicht in Frage, Du Spitzbube. Ich sitze grade an etwas, von dem mich keine Macht der Welt mehr weglocken kann: ich konzipiere eine 3D Engine - und ich werden den Sourcecode in Lazarus unter Linux schreiben und zwar mit OpenGL ohne SDL. Zumindest werd ich es versuchen.

Tipps kannst Du natürlich immer haben, aber - schreiben musst Du Dein Memo schon selbst.
Viele Grüße
Traude

Es erschwert aber auch vieles. Wenn oben im Text einen Buchstabe eingefügt wird, dann musst du durch alle Buchstaben durch und die Position aktualisieren. Du solltest den Text so oder so auch auf Zeilen aufteilen. Und anhand dieser Zeilen kannst du sehr einfach feststellen wo sich die Maus befindet und dann innerhalb der Zeile bräuchtest du nur noch die X Position herausfinden.


Würde ich so sagen. Wobe ich in meiner Font Bibliothek für jedes Wörter ein eigenes "objekt" habe. Eigentlich ist es nur eine ziemlich spannende Pointerkonstruktion.

PS: Ich habe aktuell nicht mal genug Zeit für meine eigenen Sachen. Aber auch schon etwas wirklich großes in der Queue. Mehr als Input kannst du also nicht erwarten.

Beim einfügen musst du die Zeile sowieso neu zeichnen. Dann kann man X Position auch gleich updaten oder nicht ? So mache ich das bei meinem PLEdit im Moment .
Ich müsste mir sowieso noch mal überlegen wie ich die Text Verwaltung bei meinem PLeditor Optimieren kann.
Z.B. kann ja ein Soruce-code schnell mal über 1 oder 2 MB groß werden.
Ist mir zwar noch nie passiert. Aber das macht ja nix.
Ich frage mich auch, wo da die grenze ist. Bei KDE habe ich mal irgendwo gelesen, werden immer nur 1024 KB auf einmal geladen.
Naja, das lesen ist ja kein Problem, aber das Speichern *G*....


Das reicht doch... besser als nix *G*

Die Idee die Objekte zusammen zufassen klingt nicht schlecht.

Wobei mein Ziel währe es, irgendwie eine Vorlage zu erstellen wo ich die Verwaltung leicht ändern kann.
Weil das stört mich noch bei meinem PLEditor, sobald ich die Vorlage ändere muss ich recht viele Anpassungen vornehmen, ich dachte mir schon für diesen Zweck eine art Bases Klasse zu erstellen. Aber die Frage ist, würde das so gehen ?
Das Ziel ist es halt, dafür zu sorgen, das man die Verwaltung der Buchstaben, jeder Zeit KOMPLETT änder kann, ohne das es der User bzw. der Programmier Merkt.
Mein eigentliches Ziel ist es auch, die Verwaltung vom Zeichnen zu trennen, Praktisch, dass es eine Klasse gibt die sich um die komplette Verwaltung kümmert dazu gehört das Löschen/Einfügen/Bearbeiten des Textes sowie eine Klasse die sich um das Zeichnen kümmert.
Zum Schluss so eine art User Manger, der sich darum kümmert, dass die Events weiter geleitet werden. So währe es nämlich möglich, die gleiche Klasse für OpenGL zu nutzen und auch für Canvas. Man könnte auch Praktisch für jede Variante, Besonderheiten hinzufügen.

Da OpenGL ja den GFX unterstütz, könnten auch bein schreiben Animationen, Viedos und der gleichen abgespielt werden.
Eigentlich möchte ich auch so eine komplett eigene GUI aufbauen auf diese art und weise. Das Problem ist halt nur die Frage, wie könnte so eine Klassen Strucktur aussehen ?

Ich meine bei GTK1 ist das genauso: Die Grundlagen werden von einer Klasse gemacht, das Grafische sowie der rand von einer anderen.
Ich meine auch das der Rand vom Fenster Menger gezeichnet wird.
Das hätte recht viele Vorteile für eine GUI bzw. für eine Editor Komponente. eine andere Frage währe auch, sind denn auch Tabellen Möglich ?
bzw soll es Möglich sein, Tabellen und andere Objekte zu zeichnen und zu verwalten ?

Ich weiß auch nicht warum, aber Tabellen haben irgendwas Magisches an sich, was ich faszinierend finde.
Mit Hilfe der genannten Ziele sollte es auch denkbar sein, das jede Celle in einer Tabelle ein eigene Instantaz der Editor Klasse wird. Dann währe es ein Kinderspiel z.b. Tabellen in Tabellen zu machen. und auch noch andere Spielereien.....

Das wichtigest dürfte wohl sein, dass die Klassen-Strucktur und die Verwaltung der Objekte gut durchdacht ist.
Z.B. würde es sinn ergeben eine Doppelt Verkette Liste zu benutzten ? ich würde sagen ja, weil ich muss ja häufig Objekte einfügen oder Löschen. und das durchgehen in einer Schleife um ein bestimmten Objekt Index zu suchen, sollte doch schneller sein, als in einem Array ein Objekt einzufügen wie es z.b. bei ObjectList gemacht wird. Wobei einige meinten das die ObjectList eigentlich schnell genug ist.


Ich glaube ich werde noch mal ein kleines Test Projekt aufmachen um die Frage zu klären, ob ich Formatierungen zu Objekten zusammen fassen kann.

Ich finde diese Thema recht Interessant und auch Spanend.
z.b. meine ich auch, dass es in Windows so ist, das ein TEdit eigentlich ein TMemo ist. Halt nur mit einer Ziele. Ist das nicht Speicherplatzt
Verschwendung ?

_________________
MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus

Dort gibt es die Native RFT Editor Komponente: http://mwcs.de/mwkedit.html
Nach einigen Sucherei habe ich sie doch noch gefunden.
Der Autor nennt sich xaromz und ist Mitglied im DP.

_________________
MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus

Sourcecode kann nicht mal eben schnell 1-2 MB groß werden. Entwickler die so etwas machen müssen entweder einen sehr sehr guten Grund haben oder keine Ahnung haben wie man Code strukturiert. Nichts desto trotz sollte eine Sourcecode Komponente schon mit so etwas klar kommen. Aber hier kommt die Einschränkung. Wenn du so eine Komponente haben will. Da gehört dann aber mehr dazu als nur 1-2 MB Code anzuzeigen. Und da solltest du dir klar werden was du eigentlich machen willst. Willst du eine komplette GUI machen oder nur ein paar Komponenten. Eine komplette GUI ist da schon etwas ganz anderes als nur eine Komponente. Und da kannst du auch nicht jetzt eine Komponente basteln und später eine GUI drum rum. Das wird dann scheitern. Du kannst auch nicht sagen du willst eine alles könnenden super komplexe GUI. Okay. Sagen wirst du es schon können. Das Projekt wird aber trotzdem scheitern. Ich hoffe du versteht worauf ich hinaus will.

Allerdings wenn du selber eine schreiben willst, dann wäre es ja nur Fair ein eigenes Thema dafür aufzumachen und das nicht in Traudes Projekt zu besprechen. Und solltest du dann was haben was man benutzen kann etc dann kann man da immer noch ein Projekt draus machen. Deswegen wäre es schön, wenn wir Fragen die nichts direkt mit Traudes Projekt zu tun haben ins Allgemeine verlegen.

Eine Eigene GUI zu haben währe nicht schlecht und im Prinzip habe ich auch schon eine, Naja ein Anfang. mir geht es eigentlich nur darum,
ein Editor Komponente zu schreiben.
Eigentlich nur für die Entwickler, allerdings habe ich heute Angefangen eine zu schreiben mit der man z.b. RTF Text erstellen werden soll.

Ich finde meine Vorgehensweise nicht schlecht, ich mache das so wie du es im Prinzip vorgeschlagen hast.
Somit müsste ich speicher Platzt sparen. Jetzt ist nicht mehr jeder Buchstabe ein Object sonder sie werden zusammen gefasst.
Allerdings habe ich jetzt auch ein anderes Ziel vor Augen. Ich denke das passt besser in diesem Thread oder ?
(Wenn ich das richtig sehe).

Mir geht es darum sowas wie eine einfache kleine RichEdit Komponente zu schreiben, die aber nicht Kompatibel sein muss mit der RichEdit Komponente von Delphi, währe zwar vorteilhafter aber dafür könnte ich später immer noch ein Warper Komponente drum herum schreiben.

_________________
MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus

Mal nochwas zu dem "roter Text - Blauer Text" Beispiel.
Ich würde Lossys Vorschlag mehr wie OpenGL interpretieren:

[FARBE: rot]Das ist ein Roter Text. [FARBE: Standard] Das hier ist [FETT: Ja] Text. [FARBE:Blau]Hier ist [FETT: Nein] blauer Text.
Das ist ein Roter Text. Das hier ist Text. Hier ist blauer Text.

Das heißt der Status bleibt solange bis nix neues gesetz wird.
Falls man einen Markierten abschnit (von bis ist bekannt) ein neues Attribut geben will, dann setzt man das am Beginn, und durchwandert den abschnit und löscht alle anderen Angaben zu diesem Attribut innerhalb des Textes - bis auf das Letzte was vorher da war. Das schiebt man (falls sein wirkungsbereich über den Markierten Bereich hinaus geht) ans Ende des markierten Bereichs. Findet man keine andere Angabe zu dem Attribut, wird am Ende der Standardwert für dieses Attribut gesetzt.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

So ähnlich habe ich das auch vor....
Ich werde morgen den Soruce-Code hochladen, viel ist es aber noch nicht, es zeigt halt nur den Weg den ich genommen habt.
Evlt. könnt ihr noch Idee zum Optimieren und Verbessern. Das Prinzip ist eigentlich recht einfach. Überraschenderweise bin ich auch schon recht weit gekommen.
Diese Idee hatte ich bisher noch gar nicht ausprobiert. Nicht in dieser Form.

Evlt. könnte Traude ja das als Grundlage nehmen. Ich zeichne zwar auf einen Canvas, aber ich denke das lässt sich schnell Anpassen.

_________________
MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus

Ich bin der Meinung, dass es nicht direkt mit dem Projekt von Traude zu tun hat, sondern nur um die generelle Herrangehensweise eines Memos/RTF Komponente geht. Das ist zwar das gleiche Themengebiet aber es sind trotzdem zwei ganz unterschiedliche Baustellen. Entsprechend habe ich es vom Meinungsthread glPasGUI abgetrennt.