Kontrolka edycyjna - rozwazania

Chce napisac kontrolke edycji textu. Od zera. Jest to zadanie niesamowicie zlozone, czy mi sie uda nie wiem, ale zaczynam. Rozwazam teraz hierarchie klas obslugujacych text, mam, tak:

TDocument
|
TSection
|
TParagraph

Zastawiam sie czy warto zejsc jeszcze nizej, do np. TLine czy ten poziom bedzie ok... Co Wy na to?

Drugi problem to elementy dodatkowe w texcie, takie jak tabele i grafa. Otoz caly dokument rozpatruje jak powierzchnie papieru zlozona z kartek poustawianych jedna nad druga, czyli wstega papieru. Na tej wstedze bede rysowal zawartosc poszczegolnych klas buforujacych dokument. No i tu tez sie zastanawiam nad rozwiazaniem problemow typu kilka kolumn. Wyobrazam sobie rozwiazanie nastepujace: dziele te wspomniana wstege na ponumerowane obszary i kazdemu nadaje atrybuty jego zawartosci: text, grafa, tabela itp. Czyli gdy dokument bedzie zawieral tylko text to bedzie to jeden obszar:

|----- ---|
| |
| 1 |

gdy jednak wstawie wewnatrz, w jakims fragmencie kilka kolumn, to ten jednolity obszar zostanie podzielony na 2 osobne( gora i dol) oraz tyle powierzchni mniejszych wewnatrz ile kolumn ustale:

|-----------|
| 1 |

| | | |
| | | |
| 2| 3 | 4 |
| | | |

Podobnie bedzie po wstawieniu grafiki lub tabeli.

No i teraz rysujac zawartosc dokumentu w kontexcie urzadzenia (monitor, drukarka) bede wypelnial odpowiednie obszary po kolei wg numeracji.

Czy myslicie ze ta logika jest ok?

pozdrawiam

ps. nie wiem jak wyjda te wstawki pseudograficzne, przepraszam ale nie mam tu czcionki nieproporcjonalnej

ps2. szydercom od razu dziekuje, innymi slowy, nie masz nic do wniesienia nie zabieraj glosu, dziekuje

Jak podejrzewalem cisza... warto dawac inne tematy w ogole? Kogos to interesuje?

:( szkoda

Witam...
Co do klas - myslisz, ze paragraf wystarczy? A co, jesli bedziesz chcial wyrownac teskt, zawinac go, albo sformatowac w jakikolwiek sposob. Zastanawiam sie jak masz zamiar to rozwiazac. Gdybys napisal z grubsza, za co bedzie odpowiadala ktora klasa, byloby prosciej.

Wybor klas oparlem o obserwacje Worda. Klasa Paragraph (czyli akapit) jest wlasnie ta jednostka ktora na najnizszym poziomie przyjmuje formatowanie typu wyrownanie czy zawijanie.
Klasa ta bedzie miala w sobie ciag znakow i wlasciwosci wskazujace na parametry pojedynczych znakow, ale tylko tych ktorych ustawienia (kroj, czcionka, odstep, kolor i milion innych :) bedzie inny niz globalne ustawienia paragrafu.
Klasa TSection odpowiada wordowskie sekcji (popatrz jak word to obsluguje) ona bedzie odpowiadac np. za numeracje stron i pare innych rzeczy. A TDocument to oczywiscie caly dokument (tu beda metody zapisu/odczytu, ogolne dane dokumentu, sterowanie wyswietlaniem itd.
Do tego jeszcze wizualna kontrolka TWordProcessor oparta o TWinControl (delphi) ktora bedzie posiadac wszystkie gadzety zwiazane juz z samym oknem edycji: "kartke papieru", paski przesuwania, linijki, obsluga menu kontextowego i inne.

ot co :-)

Nie znam sie na graficznej edycji i renderingu tekstu, ale nie rozumiem twojej hierarchii klas... tzn. dlaczego Paragraf jest Sekcja a Sekcja jest Dokumentem? (bo tak to przedstawiles).

Nie wiem czy dokladnie o to ci chodzilo ale ja zrobilbym tak:
(hierarchia zawierania nie klas)
(banalny przyklad w brzydkim pseudo-jezyku)
(zakladamy ze wszystko dziedziczy od TDocEntity)

TDocument
- entities: array TDocEntity
  - 1: TDocParagraph
  - 2: TDocParagraph
  - 3: TDocFrame
    - text: array TDocEntity...
  - 4: TDocTable
    - header: TDocParagraph
    - [columns,rows] array TDocEntity...
...

Ilustruje to prosty dokument z dwoma akapitami, ramka z blizej nieokreslona zawartoscia i tabela.

EDIT:

Renderowanie dokumentu polegalo by na rekursyjnym wywolywaniu metody Render w kolejnych sub-elementach.Wiec np. TDocTable wywoluje Render headera i wszystkich komorek, laczy je, dodaje ramki i zwraca do TDocument.

Troche niefortunnie to przedstawilem:

TDocument
|
TSection
|
TParagraph

bo chyba do tego pijesz. Otoz nie jest to hierarchia dziedziczenia klas choc mozna tak to odczytac, a hierarchia ich zaleznosci, czyli TDocument zawiera obiekty klasy TSection, a TSection sklada sie z TParagraph'ow.

Zatem deklaracja wygladac bedzie jakos tak:

TDocument = class
Sections: TSections; //list of TSection
...

TSection = class
Paragraphs : TParagraphs; //list of TParagraph

Czyli mniej wiecej zbiezne z tym co proponujesz.

A z tym renderowaniem to nie tak hop siup. Nie moze sobie na wlasna reke renderowac kazdy sub-element, bo wszak nie zna miejsca przeznaczenia wyniku, ktory musi byc dopasowany do juz wyrenderowanego fragmentu dokumentu.
Poza tym w danej chwili widac na ekranie tylko czesc dokumentu, wiec musi byc mozliwosc z poziomu klasy zarzadzajacej od gory wywolania rysowania tylko potrzebnego (widocznego) fragmentu. A nie jest ona w stanie wiedziec gdzie wypadnie widoczny fragment jesli go predzej nie narysuje. Dlatego musi byc jakis mechanizm oddzielny do zarzadzania powierzchnia dokumentu i rednerowaniem a osobny od przechowywania danych do renderowania. Oba trzeba by polaczyc jakims mechanizmem precyzyjnie wskazujacym co w danej chwili trzeba wyrenderowac.
To kurcze skomplikowana sprawa.
Dzieki, ze sie udzielasz, to mi bardzo pomaga :-)
pozdrawiam

Okreslenie rozmiaru moze miec miejsce juz w funkcji Render, np. podajesz na parametr oprocz urzadzenia czy bitmapy rowniez prostokat docelowy przez referencje i ewentualne zezwolenie dla sub-elementu modyfikacji tego prostokata. Alternatywnie przed wywolaniem Render nalezalo by przeprowadzic negocjacje wielkosci gdzie elementy komunikowalyby sie w celu ustalenia optymalnego podzialu, ale nie mam konkretnego pomyslu jak to zaimplementowac.

Zygfryd, a moze sie przylaczysz? :> Bo widze, ze kumasz baze.
Wiem, ze robisz co innego, bo po www lazilem, ale mi sie nie spieszy, nikt nie goni.
Jakbys chcial to zapraszam :-)

Niestety juz mam wiecej do roboty niz czasu, szczegolnie ze sesja za pasem.