TextInputCanvas - konzeptionelle Gedanken, Vorgehensweise, Umsetzung

[Slipstream]

Zitat von hansklok:

Genau um die Struktur geht es mir. Wie könnte das Aussehen?
Eine Paragraph besteht aus Characters und jeder Character hat sein eigenen Style. Das gesamte Dokument besteht aus Paragraphs.

Nicht jedes einzelne Zeichen benötigt seinen eigenen Style, der sich nicht nur in fett, kursiv usw. erschöft, sondern auch Farben, Hoch- und Tiefstellungen, Fontwechsel usw. beinhaltet.

Du kannst dir als Beispiel einmal die RichEdit-Definitionen anschauen oder einfach mit einem normalen Texteditor eine RichEdit-Datei aufmachen und dir die Steuerzeichen anschauen. Wenn du was lernen willst, dann definierst du dir aber selber eine Struktur, und zwar erst einmal auf einem großen leeren weißen Blatt Papier mit Bleistift, damit du bei Bedarf radieren kannst. Du benötigst z.B. ein einleitendes Zeichen, das dem Parser sagt: Achtung, hier kommt ein Steuerzeichen, und ein Ende-Zeichen, wie hier z.B. das /. Wird dann im Text eines der Zeichen, die du als Steuerzeichen verwendest, geschrieben, musst du das kenntlich machen, man nennt das auch "maskieren".

Dann möchtest du Absätze vielleicht nicht nur linksbündig ausgeben, sondern ebenso rechtsbündig, mittig oder im Blocksatz. Auch dafür musst du dir funktionierende Strukturen ausdenken. Diese sind dann auf den gesamten Absatz anwendbar.

Im Grunde musst du dir erstmal alles aufschreiben, was der Texteditor so alles können soll. Du kannst das von einem professionellen Texteditor abschauen, z.B. von OpenOffice, wenn du kein MSWord hast.

Ich denke, du warst da bereits auf der richtigen Fährte.

[p80286]

Zitat von Slipstream:

Zitat von hansklok:

Genau um die Struktur geht es mir. Wie könnte das Aussehen?
Eine Paragraph besteht aus Characters und jeder Character hat sein eigenen Style. Das gesamte Dokument besteht aus Paragraphs.

Nicht jedes einzelne Zeichen benötigt seinen eigenen Style, der sich nicht nur in fett, kursiv usw. erschöft, sondern auch Farben, Hoch- und Tiefstellungen, Fontwechsel usw. beinhaltet.

Wenn Du nicht permanent rechnen willst, dann hat jedes Zeichen seine eigenen Attribute. RTF,HTML und alle anderen Formate beschreiben ja nur die Texteingabe. Die Darstellung des Textes ist da eine ganz andere Baustelle.

Gruß
K-H

[hansklok]

Vielen lieben Dank für die zahlreichen Beiträge. Der letzte Beitrag von p80286 trifft es ganz gut. Die Struktur an sich habe ich. Mir geht es um deren Darstellung innerhalb eines Canvas, so das man sie auch bearbeiten kann a la WYSIWYG. Dazu habe ich mir folgende Gedanken gemacht:

Ein Absatz besteht aus einer Zeile. Ist diese Zeile länger als die Canvas Breite, wird diese umgebrochen. Also gibt es innerhalb von Absätzen Codeblöcke, die jeweils die Zeilen enthalten. Geht eine Textzeile also über zwei Zeilen (wegen des Umbruchs), so muss der Absatz 2 Codeblöcke enthalten. Codeblock 2 bezieht seine Position dann aus der Position des vorherigen Codeblocks.
Das Dokument wiederum hat dann eine Liste von Absätzen, die es dann untereinander darstellen kann. Analog zu den Codeblöcken oben, beziehen die Absätze ihr Position jeweils aus der Position und Höhe des vorherigen.

Das sind die Gedanken zur Darstellung. Nun gilt es einen Weg zu finden, Zeilen innerhalb des Canvas bei der WYSIWYG-Eingabe umzubrechen, also einen neuen Codeblock innerhalb des aktiven Absatzes anzulegen. Welches Absatz und welcher Codeblock aktiv ist, müssten anhand der Koordinaten des Mauszeigers errechnet werden. Ebenfalls, an welcher Stelle sich der Cursor (Caret) befindet, um Text weiter einzugeben.

Eine Textzeile besteht aus Wörtern. Diese haben z.B. im Constructor fest definierte Anfangswerte für Größe, Schriftart, Schriftfarbe etc. Wird ein Teile des Wortes markiert und die Werte geändert, müsste also innerhalb des WordsArray der Textzeile an der entsprechenden Stelle ein neues Wort eingefügt werden. Dann mit den neuen Eigenschaftswerten.

Meine Gedanken dazu.

Was dann später noch dazukommt, und da habe ich überhaupt keine Ahnung, wie man, damit man sich den Arbeitsspeicher nicht zukracht, immer nur den benötigten Ausschnitt auf dem Canvas darstellt. Oder anders, wie man eine Seitendarstellung (A4 etc.) machen kann, die kontinuierlich scrollt, aber ebenfalls nicht den Arbeitsspeicher crasht.

[Slipstream]

Zitat von p80286:

Wenn Du nicht permanent rechnen willst, dann hat jedes Zeichen seine eigenen Attribute. RTF,HTML und alle anderen Formate beschreiben ja nur die Texteingabe. Die Darstellung des Textes ist da eine ganz andere Baustelle.

Sagen wir mal, ich gebe mit TextOut eine Zeile aus, dann hab ich doch vorher schon alles andere berechnet: Schriftart, -stil, -grösse, -farbe usw.: TextOut(X, Y, MeineZeile); Ich muss vor der Ausgabe also nur "rechnen" (den Prozessor beanspruchen), wenn sich in der Zeile Änderungen an diesen Parametern ergeben, z.B. ein {b} für die Einleitung von Fettschrift. Ich brauch also einen Parser für das Text-Script (Text mit Steuerzeichen), der alles veranlasst. Das stelle ich mir so vor, dass ich eine Klasse habe, die eine Struktur anbietet, in der ich z.B. eine Zeile zusammenstellen kann. Im Parser muss ich mir auch nicht jedes Zeichen anschauen, sondern immer nur nach den Steuerzeichen suchen. Alles zwischen zwei Steuerzeichen bleibt unverändert. Findet er ein Steuerzeichen, muss er darauf mit einer Methode reagieren, die die Schriftparameter setzt. Dabei habe ich im Speicher in einer anderen Struktur Platz für einen kompletten Satz von Steuerzeichen (eine weitere Klasse, aus der ich Steuerzeichensätze instanziere), den ich durch das Script-Steuerzeichen identifizieren kann. Habe ich eine Zeile zusammen, wird die im Schleifendurchlauf ausgegeben, wobei die Schleife nur einmal durchläuft, wenn in der Zeile keine Steuerzeichen sind.

Die Länge der Zeile ist nochmal eine andere Baustelle, das hab ich jetzt erstmal unterschlagen. Aber ich denke, wenn ich in meiner Klassenstruktur jedem Zeichen alle verfügbaren Attribute verpasse, muss ich mehr rechnen. Vielleicht irre ich mich ja auch, dann wäre es lieb, wenn du mir genauer erklärst, warum man bei deiner Vorgehensweise weniger rechnen muss.

Zitat von hansklok:

Ein Absatz besteht aus einer Zeile. Ist diese Zeile länger als die Canvas Breite, wird diese umgebrochen. Also gibt es innerhalb von Absätzen Codeblöcke, die jeweils die Zeilen enthalten. Geht eine Textzeile also über zwei Zeilen (wegen des Umbruchs), so muss der Absatz 2 Codeblöcke enthalten. Codeblock 2 bezieht seine Position dann aus der Position des vorherigen Codeblocks. Das Dokument wiederum hat dann eine Liste von Absätzen, die es dann untereinander darstellen kann. Analog zu den Codeblöcken oben, beziehen die Absätze ihr Position jeweils aus der Position und Höhe des vorherigen.

Das sind die Gedanken zur Darstellung. Nun gilt es einen Weg zu finden, Zeilen innerhalb des Canvas bei der WYSIWYG-Eingabe umzubrechen, also einen neuen Codeblock innerhalb des aktiven Absatzes anzulegen. Welches Absatz und welcher Codeblock aktiv ist, müssten anhand der Koordinaten des Mauszeigers errechnet werden. Ebenfalls, an welcher Stelle sich der Cursor (Caret) befindet, um Text weiter einzugeben.

Eine Textzeile besteht aus Wörtern. Diese haben z.B. im Constructor fest definierte Anfangswerte für Größe, Schriftart, Schriftfarbe etc. Wird ein Teile des Wortes markiert und die Werte geändert, müsste also innerhalb des WordsArray der Textzeile an der entsprechenden Stelle ein neues Wort eingefügt werden. Dann mit den neuen Eigenschaftswerten.

Meine Gedanken dazu.

Was dann später noch dazukommt, und da habe ich überhaupt keine Ahnung, wie man, damit man sich den Arbeitsspeicher nicht zukracht, immer nur den benötigten Ausschnitt auf dem Canvas darstellt. Oder anders, wie man eine Seitendarstellung (A4 etc.) machen kann, die kontinuierlich scrollt, aber ebenfalls nicht den Arbeitsspeicher crasht.

Ich weiss nicht so recht, was du mit "Codeblock" meinst. Man muss hier wirklich sehr sorgfältig und gründlich vorgehen und alle Eventualitäten berücksichtigen. Und am besten man fängt erst zu programmieren an, wenn man das ganze Konzept vorher auf Papier ausgearbeitet hat.

Angenommen, du hast eine Zeile auszugeben, die wie die folgende aussehen soll:

Wenn man ein Fachbuch über das Schreiben von Fachbüchern schreibt, gerät man in eine vertrackt selbstreflexive Position.

Dann berechnest du erstmal die Länge der Zeile, indem du die Längen jeder Einheit dieser Zeile addierst. Als Einheit verstehe ich Zeichen, die zwischen zwei Anweisungen stehen, hier erstmal das W mit grösserer Schrift und in Fett: L := TextWidth(MeinText); natürlich mit vorangegangener Einstellung der Textparameter. Zu diesem Zweck hast du einen virtuellen Canvas im Speicher. Ist die gesamte Zeile (alle Resultate der verschiedenen Textlängenberechnungen addiert) länger als die Breite des Ziel-Canvas, musst du die Zeile kürzen.

Ich hab das auch noch nie gemacht, obwohl mir schon ein paarmal der Gedanke kam, das war mir aber dann doch zuviel Arbeit. Heute verwende ich auf Arbeit eine professionelle Lösung von einem Drittanbieter, um professionell aussehende Texte ausgeben zu können. Da stecken garantiert ungezählte Mannjahre an Arbeit drin. Trotzdem bin ich sicher, dass du, wenn du nach und nach das ganze Konzept erarbeitet hast, zu einer funktionierenden Umsetzung kommst. Du musst halt nur vorher wissen, was du alles brauchst und dir dann überlegen, wie du diese Dinge in Delphi realisierst, also eine Klasse, die deine mit dem Parser zu analysierenden Zeilen enthält. Da du mit D2010 arbeitest, hast du Unicode-Strings und kannst in so einen String einen ganzen Absatz reinpacken, das wäre dann eine Zeile in der Klassenstruktur, oder eine Stringliste. Wie man die Berechnungen jetzt alle so macht, willst du ja eigentlich selber herausfinden, um was zu lernen, wenn ich das richtig verstanden habe.

[hansklok]

Hihi, ich glaube, wir haben uns falsch verstanden. Ich finde Deine Vorgehensweise schon richtig. Wonach ich zur Zeit suche, und das unterscheidet sich etwas von Deinen Ausführungen, ist eine Variante ohne das es bereits eine Struktur (Textdatei) gibt, eine solche zu schreiben, eben visuell.

Und eine vorhandene könnte so aussehen:

Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<document>
  <paragraph>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.</paragraph>
  <paragraph style="1">Lorem ipsum dolor sit amet, 
    <textstyle="2">consetetur 
      <textstyle="3">sadipscing</textstyle>
     elitr</textstyle>
    , sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua</paragraph>
</document>

Du hast nach den Textblöcken gefragt. Die Anregung habe ich von hier bekommen. Das ist allerdings nur eine Projekt zur Darstellung, jedoch kann man nicht den Text auf dem Canvas bearbeiten.

[stahli]

Ich lese interessiert mit, da ich gerade an einem ähnlichen Teilprojekt arbeite...
Ich glaube nicht, dass wir uns konkret gegenseitig helfen können, will aber mal meinen Stand kurz beschreiben:

Hier habe ich eigene "Controls" gezeigt, in denen ich grundlegend schon arbeiten kann: http://www.delphipraxis.net/185623-m...-controls.html

Ich zeichne dazu die "Controls" lediglich auf den Formularcanvas und zeichne auch den Cursor einfach als Strich in das Bild.
Grundsätzlich fühlt sich das im Ergebnis schon wie richtige Controls an (Selektion von Text und C&P geht aber noch nicht).

Gerade bin ich dabei, auch einen Editor für mehrzeiligen Text aufzubauen und als zweiten Schritt einen Code-Editor mit Syntax-Highlighting etc.

Ich parse den Roh-Text dazu in einzelne Worte, z.B. so:
"Ich"
" "
"parse"
" "
"den"
...

Jedes Wort wird in einem Objekt verwaltet und zusätzlich bestimmte Statusinformationen (Bedeutung, Hint etc) die der Editor dann für die Darstellung des Textes verwenden kann.

Der Text wird wiederum in Zeilen untergliedert, die dann jeweils mehrere Wörter enthalten.

Der Editor wird an die Zeilen gebunden, erstellt dann für jede gebundene Zeile eine Art Panel ohne Rand und für jedes Wort in der Zeile ein Edit ohne Rand. Die trennenden Leerzeichen sind in dem Sinne auch Wörter.

Der Editor zeichnet mindestens die sichtbaren Zeilen und schätzt zunächst die Gesamthöhe für den Gesamttext ab um die Scrollbar darzustellen. Wenn Zeit ist kann er auch mehr Text rendern, um genauere Daten zu haben.

Wenn dann Text in einer Zeile geändert wird muss diese als invalide gekennzeichnet und neu gerendert werden.
Die Metadaten zu den einzelnen Zeilen und Wörtern müssen in der Datenschicht verwaltet werden, die Positionen auf der Zeichenfläche aber vom jeweiligen Editor.

In jedem Fall soll bei mir eine Zeile im Editor an eine Zeile im Text gebunden werden und jedes Wort einer Zeile soll wiederum an ein einzelnes Edit gebunden werden (ohne sichtbare Rahmen).

Je Wort ist also dann jeweils ein Edit für die Darstellung und Bearbeitung (incl. Caretpositionierung bei Klick usw) zuständig.

So ist mein aktueller Ansatz, an dem ich arbeite.


Später wäre ein RichEditor noch interessant, das würde dann schon eher zu Deinem Projekt passen. Da wäre das Zerlegen in einzelne Wörter mit zugeordneten Metadaten sicher auch weniger interessant.

[Aviator]

Zitat von stahli:

Gerade bin ich dabei, auch einen Editor für mehrzeiligen Text aufzubauen und als zweiten Schritt einen Code-Editor mit Syntax-Highlighting etc.

Ich weiß ja nicht was dein Editor später alles noch können soll, aber hast du dir mal die SynEdit Komponenten angeschaut? Die haben auch eine Syntax-Highlighting Funktion und vieles mehr. So in etwas wie der Code Editor in Delphi. Syntax-Highlighter kannst du dir auch selbst erstellen und dem SynMemo zuweisen.

Wäre vielleicht weniger Arbeit. Es sei denn, deine Komponente soll später noch 1000 Dinge mehr können als die SynEdit Komponenten es können.

[stahli]

Ich brauche eine Lösung, die spezielle Rahmenbedingungen erfüllt. Daher habe ich das von Null an aufgebaut.