Re: System.Windows.Forms Coding Competition

On Tue, 2004-12-14 at 23:00 +0100, Carl-Adam Brengesjo wrote:
> IMHO, the TextBox stuff needs some overhauling, it's not very pretty 
> with internal method calls between TextBox and TextBoxBase as it is now.
> And RichTextBox needs to be implemented at some point -- it would also 
> be nice to get RTB working before another certain (name omitted) 
> CLI/.NET project does ;)

Internal methods are unavoidable in TextBox/TextBoxBase without breaking
the public/protected API. The nested internal classes in TextBoxBase
(the B-Tree and gap buffer backend stuff) still need to be hooked up to
the frontend of the class and the text layout managers still need to be
written (i.e. concrete subclasses of TextLayout). Also, some extra,
non-spec, functionality for string drawing and measurement will be
needed in System.Drawing.Graphics for efficiency's sake (see the
TextBoxBase.TextSlice class); this should be protected by Code Access
Security once that is implemented. The backend should serve well, with
some modifications, for supporting RichTextBox, but getting TextBox
working should be the priority; I borrowed ideas from Java's swing
toolkit (gap buffer) and GTK+ (B-Tree) in writing it, so it's a sort of
hybrid of the two approaches. It was my hope that it would be the best
of both worlds, however, if it turns out to be a problem getting it to
work for RichTextBox, at least some of it should be salvageable; both
pure implementations, swing and GTK+, are capable of handling it, so the
hybrid should be as well imo, though. Either way, the braindead API
makes it impossible to achieve a complete and efficient implementation
in a purely managed and 100% spec-compliant fashion. With a minimum of
API breakage (the as-yet-unwritten sys.drawing mods), however, a purely
managed approach can be efficient enough not to cause people to start
gouging their eyes out waiting for the damn thing to render something as
simple as a short paragraph.


Rich