Setback in Text Editor Land

We took the baby with us up to Wharton this weekend so my wife could resume her MBA classes. That left me to look after the munchkin, and when she was asleep, alone in the hotel room with nothing pressing begging for my attention. Sweet! Uninterrupted hacking time!

I went back to working on RichTextEditor, which has been my obsession these last few months. My goal for the upcoming release is to add paragraph formatting, including the ability to add shading and borders. Since there are fields called things like wShading and wBorders in the underlying Rich Edit control that RichTextBox is a wrapper for, I thought I'd be able to do it without too much work. Foolish Craig.

The problem is that, although the structures listed in the Platform SDK support the full range of things that can be described in a Rich Text document, the Rich Edit control does not. It stores the values so that you can roundtrip the text with (say) Word, but it doesn't change the way that anything gets displayed. So you can, for example, tell the control to draw borders around a paragraph all you want, but it won't do a damn thing about it.

Now, that's not the real showstopper. I actually thought that might be the case, and came up with a few strategies for working around it. Specifically, what I tried to do was to let the Rich Edit control draw the text, and then draw borders and shading over the top of it with my own GDI+ calls. I even got a prototype working, drawing a shaded rectangle with a border in a fixed location over some text.

Unfortunately, the prototype displayed a problem that would eventually lead me to abandon my efforts: the stuff I was drawing flickered like mad. I spent an evening working through the problem with the ever-generous Ian Griffiths, but in the end we came to the conclusion that the only ways to do what I want involve horrendous hacks on top of nasty grungy bits on top of the hacks I'm already doing. Things like positioning a layered window over top of the RichTextBox window and drawing on that. Blech.

What it comes down to is that the Rich Edit control (and by extension RichTextBox and derivatives) is an 80% solution. Most of the time, you can get it to do what you want. But if you're an exacting bastard like me, and you just can't do without this feature or that, you're in the other 20% and you're screwed.

So, what am I going to do? First, I'll finish up RichTextEditor so that anyone who only needs stuff in the 80% can benefit from it. After all, it gets lots of good features from the underlying Rich Edit control, like sophisticated line breaking and support for East Asian languages. But once I get that out of the way, I'm going to write my own text editor control, from scratch, in managed code.

It's exactly the sort of “reinvent the wheel” scenario that I was hoping to avoid, but I don't think there's any way around it. And I'm looking forward to the experience, too, especially if I can pull it off the way I envision it. My only disappointment is that further development of FlexWikiPad is going to be delayed by however long it takes me to write a stable text editor control. Sigh.