Gemeinschafst projekt: rtf änliches komponente !

[schnullerbacke]

Dann etwickel mal ein einfaches Fenster mit der dazugehörigen Verarbeitungslogik um das hinterher als Komponente in der IDE zur Verfügung (z.V.) zu haben. Das geht bei Lazarus nur per TForm, bei Delphi/Kylix hat man wenigstens noch TFrame um sowas zu machen. Beides ist höchst unelegant weil das nicht zu einer Komponente führt.

Eine "composite component"(zusammengesetzte Komponente) stellt sich für den Programmierer als eine einzige Komponente wie z.B. TEdit dar. Er braucht über die interne Verarbeitung der Komponente nichts wissen und braucht nur per Propertys auf die nötigen Sachen zugreifen. Bei einer Textverarbeitungskomponente teilt er der Komponente nur mit, welches Textfile geladen werden soll, selbst das kann die Komponente noch selbst z.V. stellen. Er könnte aber von außen eine Volltextsuche starten und erhält die Ergebnisliste zurück ohne dafür wissen zu müssen, wie die Textkompo das intern abarbeitet.

Genau so ist OOP zu verstehen, sequentiell alles selbst im Quelltext zusammenbauen kann man ja auch, da stellt sich nur die Frage was das soll. Es würde ja schließlich auch niemand auf die Idee kommen von Hamburg nach Rom über Tokyo zu fahren wenn er es eilig hat.

[pluto]

Ja schon richtig... wie funtknieren den die vorhanden Komponenten ?
wie z.b. eine Listbox, ComboBox, Checkbox, und so weiter !

Ich denke das Problem ist schon gelöst worden.

[schnullerbacke]

Die Frage ist weniger, wie die funktionieren sondern wie sie gebaut worden sind. Am einfachsten sieht man das daran, ob oberhalb von private, also direkt unter der Klassendeklaration irgendwelche Vereinbarungen stehen. Ist das nicht der Fall wurden sie von Hand gebaut, steht da was haben sie einen Container verwendet. Das 1te dürfte gelten, weil das Grundobjekte sind, für die vorher nichts visuelles existiert hat.

Der Witz an der visuellen Entwicklung ist aber gerade die schnelle Produktion von neuen visuellen Objekten ohne gleich wieder in den Urschlamm der OOP eintauchen zu müssen. Wieso soll ich wohl ein TEdit von Hand in meine Komponente einbauen wenn ich das auch per "klick and drop" machen kann? Mehr Overhead gibt das letztlich auch nicht, verkürzt aber die Enwicklungszeit beträchtlich. Ist ja letzlich "schißkujennum" ob ich die Komponente auf die eine oder andere Art einbaue, alleine dadurch das sie da ist bringt sie ihren Overhead mit.

So war OOP schon von Anfang gedacht, das scheint sich aber bisher nicht recht rumgesprochen zu haben. Auch bei Delphi/Kylix haben die das bis heute fröhlich verpennt. Deswegen tauchen jetzt solche Sachen wie UML auf, die eigentlich überflüssig sind wie ein Kropf. UML macht nämlich genau das auf einem Umweg möglich, also über Tokyo nach Rom. Nur was soll das am Ende?

[schnullerbacke]

So, hier mal ein snapshot von Delphi wie so was aussehen kann. Mir fehlen 2 Routinen in der unit Systems dann wären wir wohl schon nahe dran, das auch in Lazarus zu verwenden. Das darf man änder, wie es sich aus dem unit-Headern ergibt, allerdings ist die Url inzwischen tod, sodaß das keine große Rolle mehr spielen dürfte.

[pluto]

auf dem bild kann ich nicht erkennen was für unser vorhaben nütztlich sein könnten.

Ich habe OPP so verstanden: ich schreibe eine klasse also ein Bauplan für eine Komponente z.b. Jetzt kann ein und der Selbe code weiter verwendet werden indem ich z.b. eine klasse ableite.

Beispiel:
eine einfache Listbox, kann für:
- Ein Main Menu verwendet werden
- ein PopupMenu
- eine ListView
- eine comboBox
- eine Checklistbox
- eine TreeView
- und im Prinzip auch für ein einfaches Memo....

ich habe es mir noch einmal überlegt mit der RTF- Komponente.
Mein erster versuch wahr letztendlich doch garnicht mal so schlecht.

Jeder Buchstabe ist ein einfaches Objekt und wird in einer TObjectlist verwaltet und in der reinfolge wie sie in der Liste stehen angezeigt.

Dadurch haben wir später sehr viele Probleme weniger:
1: Das Bearbeiten durch die Tastertur wird sehr stark vereinfacht.
2: Das Markieren dürfte einfacher sein(bei meinem ersten versuch habe ich das leider nicht hinbekommen, weil es so langsam war und auch nicht sauber lief)
3: Das Ändern von Schiffskonfigurationen dürfte wensehtlich einfacher werden z.b. ich habe einen Text der ist rot gelb grün und jetzt möchte ich ihn auf schwarz machen.

und wir könnten auch ganz einfach BITMAP Fonts unterstützen,

wir müssten uns nur noch mit einem Problem befassen:
die Anzahl der Objekte im speicher dürfte bei größeren texten zu groß werden d.h. wir müssen die anzahl verkleinern und zwischen speichern.
z.b. ich gebe einen Text ein der ist über 400 Zeichen lang das währen dann über 400 Objekte wir könnten z.b. die anzahl halbieren und zwischen speichern in einer Datei, wenn wir das richtig machen dürfte das schnell genug sein.

Nur beim scrollen wird es Probleme geben wegen der Geschwindigkeit und wegen des Speicher bedarf.

Also ich schlage vor, jeder der dazu was zu sagen hat kann, das gerne tuen nur möchte ich einfach nicht mehr höhren das Projekt wird zu umfangreich und könnte unlösbar für mich oder uns werden.

Ich hoffe wir finden gemeinsam eine Lösung. ich habe jetzt
ein paar vorgestellt .

Welche wir davon nehmen müssen wir uns jetzt Überlegen weil auf diese Lösung baut dann das gesammte Projekt auf und ich möchte nicht immer wieder von vorne anfangen.

Egal wie lange es auch dauern mag, erst wenn es eine RTF-Änliche Komponente gibt, werde ich mich mit diesem Thema nicht mehr befassen !

[schnullerbacke]

Na eben, aber warum dann eine visuelle Komponente nicht auch visuell entwickeln, besonders dann wenn die aus anderen visuellen Objekten zusammengebaut wird?

Auf dem Bild siehst du eine Box die eine neue Klasse TCustomEditor deklariert, da hab ich schonmal eine ToolBar für die Bedienung draufgesetzt. Zusätzlich eine ScrollBox. Jetzt könnte man stickum weiter Buttons deklarieren, die passenden Icons zuweisen und deren Funkionaltät im Quellcode verankern. Und das indem man einfach das Onklick-Ereignis wie gewohnt für den Button anklickt und schon kann man den Quellcode erstellen.

Was soll denn daran nun nicht richtig sein?

[pluto]

ach so ich glaube ich verstehe dich jetzt:
du hast einfach mehre Komponenten auf einer gelegt beispiel:
ein Panel: auf dem Panel ist die Toolbar für die Bearbeitung.
unten ist eine Staturbar... naja das war nicht mein ziel.

Mein Ziel war es nur die Komponente zu schreiben das drumherum können kann/muss der User machen oder wir machen es später wie du es gesagt hast.... sowas gab es führer mal für Delphi ich glaube für "Delphi 1" habe ich sowas mal gesehen !

Ich frage mich immer noch wie Linux z.b. rtf Text da stellen kann... das muss doch auch in einer LIB drinnen stehen oder nicht

[schnullerbacke]

Das wird doch letztlich die Komponente. Du willst Text markieren also brauchst du eine Funktion mit der markiert werden kann. Das ist zumindest mal ein Mausereignis oder kann per OnKeyDown von der Tastatur ausgehen. Beides sind aber Methoden die eindeutig Teil der Komponente sind. Daran hat später der Anwendungsprogrammierer nix mehr zu suchen. Der klickt sich die Komponente auf sein Formular oder ein Panel oder ähnlich und benutzt einfach die Fähigkeiten der Komponente.

Das dient der Produktivität, das ist das Ziel eines RAD-Tools wie Delphi oder Lazarus. Nur Bytepopler sehen das nicht ein, die stricken lieber in den tiefsten Tiefen.

[schnullerbacke]

Guck dir jetzt den snapshot nochmal an, das ist das Ausgangsobjekt für die neue Komponente und dahinter die dazugehörige unit mit der Register-Prozedur. Und trenn dich schnell von dem Gedanken, das ein Objekt nur irgendein Kasten wäre der am Bildschirm auftaucht, dazu gehören seine Daten und Methoden. Die Komponente ist am Ende das Ganze das nur noch die entsprechenden Schnittstellen nach außen liefert.

Für das Ausgangsobjekt muß nun noch ein Canvas vereinbart werden, das die Darstellung des Textes übernimmt und dann baut man die entsprechenden Funktionen ein. Aber in das Objekt und nicht in das Formular, sonst kann man sich die OOP gleich sonstwo hinstecken.

#Edit

Und wenn man das schlau programmiert vergißt man irgendwelche Library's ganz schnell wieder, wer will denn vorhersagen, ob es die gleiche für jedes BS gibt. Das sind Aufgaben die das Objekt(Komponente) intern lösen muß. Und der User soll eben nicht die Mimik für den Editor einbauen, das gehört in das Objekt rein und sonst nix.

[pluto]

naja das währe das Grund aussehen.

Das mit dem Maus und Tastertur Ereignis ist schon irgenwie klar.
Auch das ich den die Positionen der einzelnen Buchstaben bei Mausklick bzw. bei einer Maus
Bewegung berechnen muss.

was mir nicht klar ist wie komme ich an den Markierten Text wieder ran. und wie kann ich die Hintergrund Farbe Vorübergehend ändern ?

[schnullerbacke]

Property's, so wie woanders. Allerdings wird das für bestimmte Teile garnicht nötig sein. Farbe ändern macht er intern, von außen bestimmst du welche Formate geladen werden dürfen, den Rest weiß das Objekt dann. Warum das Rad immer neu erfinden wollen?

Für neue Formate kann man dann den Editor erben und überschreibt die Lese- und Schreibmethode. Eventuell müssen dann noch die Format-Macros geladen werden.

[pluto]

Naja ich denke mal mit Formate meinst du Datei Formate oder ?
das wollte ich so machen, dass es eine eigene Klasse die sich um das speichern kümmert, das habe ich bei meinem Paint2 Projekt auch so gemacht.
dort habe ich das Speichern getrennt am Anfang war es fest im Code drin.

Als ich ein zweites Format einfügen wollte ging das nicht mehr da habe ich die klasse TFormatManger erstellt. und fertig. und genau so wollte ich es auch bei der RTF Komponente machen.

Ich denke mal sie könnte mit Sicherheit einige Formate unterstützen außer RTF und HTML oder ? z.b. PDF, OpenOffice Formate, Doc Formate und so weiter...

das ist aber nicht das Hauptziel.

[schnullerbacke]

Erstmal muß mal das Canvas rein, dann kümmert man sich um die Formate, das kommt dann schon.

[pluto]

Na gut aber wir sind immer noch nicht weiter mit der Verwaltung der einzelnen Buchstaben..... was schlägst du da vor ?

[schnullerbacke]

Die einzelnen Buchstaben sind nicht wirklich entscheidend, ein Buchstabe ist letztlich nur ein Sonderfall von mehrere Buchstaben. Da hat theo bestimmt was in Petto.