Hello Dimitrie,
Monday, December 29, 2003, 11:33:21 PM, you wrote:
DOP> Now, if you are familiar with the richedit problem, DOP> can you come up with a list of tasks that will eventually DOP> lead to a full blown richedit control? It is a big task, if DOP> we break it into smaller, self contained ones (like the DOP> ones you mentioned) maybe someone will start working on it.
I'll try.
First, I don't think that any part of the current richedit code can be used. It is very much of a stub.
Hard Tasks:
. COM interfaces. I have only started to implement the tom.h header file (for MinGW, but it should be easy to port). I am personally bad at COM programming (esp. in pure C)... There can be two approaches to this: a) implement everything without COM and then add simple COM wrappers. This may be easier because the official COM richedit interfaces are not very simple (for me :) b) implement everything in COM from scratch.
. Internal rich text storage - how it should be done? Structures etc. (ITextDocument, ITextRange...) Maybe have a look at GtkTextBuffer from GTK+?
. There are also some OLE interfaces, and I won't say anything here because I never used that.
Easy Tasks:
. Streaming RTF in and out of the internal storage. I have done a lot of RTF parsing/generation code, so this could help.
. Rich text rendering. This seems relatively simple, I did some multifont text rendering code in Win32 API.
. User interaction. Relatively simple too.
That's it. It seems to me that the first thing to do is an internal rich text storage specification, because every other task depends on it.