Windows Rich Text Control Development

[MyndFyre]

Hey all --

I've been giving some thought as to how I might be able to develop a very custom rich text control.  It wouldn't be a control people actually type in -- it'd be meant for output only.  Here are my tentative specs:

• Fully object-oriented
  
• Text items are stored in nodes that are linked together in a forward list
  
• Scrolling should be set line-by-line, top, bottom, or any variable number.
  
• Scrolling should either be smooth that is, each time text *should move* a pixel, it does), or clipped (text isn't redrawn until a scroll bar is released), based on the Windows Show Window Contents while Dragging setting
  

Anyone have any ideas?

[Skywing]

I would be highly interested in working on this -- however, the work is definitely going to be non-trivial.

In addition to what you have specified above, the primary feature requirements I have that I can recall off the top of my head are:

The most important thing is automatic font linking for glyphs not present in the selected font (e.g. truly Unicode enabled).  This is the primary reason why I haven't written my own control so far -- Uniscribe/MLang are a major pain to use and the documentation isn't that great.  Any control that's used for chat needs to have font linking so that blocks aren't displayed for characters not supported by the current/default font.

Other things:

- It should be easy to disable scrolling, e.g. so that a user can scroll up and select something without having the client area scrolled out from under them.
- The insertion position should be distinct and separate from the user's text selection for copy/paste.
- Formatting support (this probably doesn't need to be as extravagent as RTF, but it should support stuff like drawing text with different colors or font attributes within the same control).
- Easy to use from languages that don't have intrinsic support for COM (including non-CLR languages).  Preferably implemented as a standard Windows custom control would be.

[MyndFyre]

You've piqued my curiousity.  However, there are some areas I'm not sure about:

The most important thing is automatic font linking for glyphs not present in the selected font (e.g. truly Unicode enabled).  This is the primary reason why I haven't written my own control so far -- Uniscribe/MLang are a major pain to use and the documentation isn't that great.  Any control that's used for chat needs to have font linking so that blocks aren't displayed for characters not supported by the current/default font.

I haven't dealt with much multi-language support in my travels; are the "blocks" that you refer to those annoying rectangle things that pop up when Windows doesn't know what character to display?  I'm not particularly familiar with using Unicode (other than that I know NT natively supports it as does Java and .NET).

- It should be easy to disable scrolling, e.g. so that a user can scroll up and select something without having the client area scrolled out from under them.

I hadn't considered automatic scrolling -- which seems like a distinct possiblity -- but you make a good point.  I just assumed that the client hosting the control would scroll.

- Formatting support (this probably doesn't need to be as extravagent as RTF, but it should support stuff like drawing text with different colors or font attributes within the same control).

One of my thoughts about this was that each text node in the list would contain font and color information.

- Easy to use from languages that don't have intrinsic support for COM (including non-CLR languages).  Preferably implemented as a standard Windows custom control would be.

For me, that was assumed.  Implementing it in COM or .NET would limit the accessibility and generalizability of the control.  However, it would be nice to provide a wrapper for those environments to access it.

[Arta]

It would be nice to have a control that supported margins as well: In other words, instead of:

Code Select Expand


<user> this text is
wrapping


You would have

Code Select Expand


<user> this text is
           wrapping


I think that would look great and make things easier to read

[MyndFyre]

It occurs to me that the ability to add images in various formats may also be useful.

[dxoigmn]

One thing I liked about using a WebBrowser control to display chat, updates, etc. is that I can link a stylesheet to it to allow the user to custom define the colors.  It also is nice for showing/hiding timestamps since you just update the css file to set that particular element to hidden.  The only bad thing was the bloat.

[MyndFyre]

The only bad thing was the bloat.

That was the WORST thing.  It used at least an additional 30 or so mb of memory.  Bloat nothing.

[dxoigmn]

The only bad thing was the bloat.

That was the WORST thing.  It used at least an additional 30 or so mb of memory.  Bloat nothing.

And if you could develop a control that has similar functionality without the bloat, you'd do everyone a good service.

[Banana fanna fo fanna]

How about we all band together and write a kickass text rendering engine for it, slap on a HTML parser, and call it an ultralite browser.

[UserLoser.]

It would be nice to have a control that supported margins as well: In other words, instead of:

Code Select Expand


<user> this text is
wrapping


You would have

Code Select Expand


<user> this text is
           wrapping


I think that would look great and make things easier to read

Note: That's already possible with the current RichEdit20.dll.  See PARAFORMAT and EM_SETPARAFORMAT - My old client supported this.

[MyndFyre]

How about we all band together and write a kickass text rendering engine for it, slap on a HTML parser, and call it an ultralite browser.

That was something I was considering.  If we could develop a decent way of putting together a nice base class for text rendering, making an HTML node inherit from it shouldn't be too much of a stretch.  But I'd rather focus on one thing at a time, bearing in mind design goals such as generalizability, reuse, and extensibility, instead of having a load of feature creep.

[Arta]

Note: That's already possible with the current RichEdit20.dll.  See PARAFORMAT and EM_SETPARAFORMAT - My old client supported this.

Neat, I'll have to look into that.

[Grok]

Support embedded DIBs?

[MyndFyre]

Support embedded DIBs?

I'm not sure that I want this to create "documents" per se.  At least, that wasn't what I'd envisioned.  :-)

[MyndFyre]

So, although I haven't given this TOO much thought, I was working through some ideas and I wanted to share a little bit of the header that I started dabbling with:

RichDisplay.h

Code Select Expand


#ifdef RICHDISPLAY_EXPORTS
#define RICHDISPLAY_API __declspec(dllexport)
#else
#define RICHDISPLAY_API __declspec(dllimport)
#endif

// Handle to a text segment with individual information for text, font name, and color.
typedef HANDLE HTEXTSEG;

// This class is exported from the RichDisplay.dll
class RICHDISPLAY_API CRichDisplay {
public:
CRichDisplay(void);
~CRichDisplay(void);

};

// This class describes segments of text.  Describes text, font name and color.
class RICHDISPLAY_API CTextSegment
{
private:
BOOLEAN m_selected;
LPWSTR m_text;
LPWSTR m_font;
DWORD m_color;
HTEXTSEG m_handle;

public:
CTextSegment(void);
~CTextSegment(void);

DWORD GetSelected(OUT BOOLEAN &fSelected);
DWORD SetSelected(IN BOOLEAN fSelected);

DWORD GetText(OUT LPWSTR szBuffer, IN DWORD nMaxLength, OUT DWORD nTextLength);
DWORD SetText(IN LPCWSTR szBuffer, IN DWORD nTextLength);

DWORD GetFontName(OUT LPWSTR szBuffer, IN DWORD nMaxLength, OUT DWORD nLength);
DWORD SetFontName(IN LPCWSTR szBuffer, IN DWORD nNameLength);

DWORD GetColor(OUT DWORD &nColor);
DWORD SetColor(DWORD nColor);

HTEXTSEG GetHandle();
}

// Creates a new CTextSegment instance and retrieves its handle so that it can be used in languages that do not support
// use of C++ classes.
RICHTEXTDISPLAY_API HTEXTSEG CreateTextSegment(LPCWSTR szText, DWORD nTextLength, LPCWSTR szFontName, DWORD nFontNameLength, DWORD nColor);


So essentially, I want C++ users to be able to use classes, but I also want other language libraries to be able to interact with the library through handles.

Any thoughts?