Yeah - our RichEDit needs some work

[Phil Krylov]

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.

-- 
Best regards,
 Phil                            mailto:phil at newstar.rinet.ru