riched20: WM_SETFONT support

[Matt Finnicum]

On 6/25/06, Krzysztof Foltman <wdev at foltman.com> wrote:

> I'm definitely for using your conformance test code. And WM_GETFONT. Not
> sure about the rest - the code in my patch is based on implementation of
> EM_SETCHARFORMAT, so it's basically as good as that one.

Actually, GETFONT was a mistake - it turns out it doesn't exist for
rich edit controls.

> > 1) You need to rewrap the paragraphs, since line lengths change.
>
> Yes, but SetCharFormat already does it internally (run.c:624), so
> there's no need to explicitly call it again.

I had some issues with rewrapping not happening when I was testing
with mine, but it appears to be working fine on yours. A long line,
after being SETFONT'd to a larger font, would have overlapping text.

> > 2) Your code ignores lParam (which is supposed to specify if it
> > repaints immediately)

Ahh. Missed that somehow.

> > 3) You need to invalidate the entire control - otherwise just the are
> > the text takes up will be redrawn - if the text shrinks, then the area
> > outside it's new size won't be blanked / you'll see fragments of the
> > old text.
>
> I'm not sure how the original control is behaving - going with
> InvalidateRect, no matter if it's necessary or not, won't harm. However,
> it should be done in ME_SetCharFormat, so that both EM_SETCHARFORMAT and
> WM_SETFONT (and other functions) will use it.

Sounds good - I didn't test how SetCharFormat was behaving, but you're
right - it's probably needed by both. The redraw glitch can be pretty
obvious (just change any chunk of text to a smaller font)

> > 4) Your code (I believe) will reset the scroll position - I store it
> > ahead of time and then restore it.
>
> And that is actually wrong - keep in mind that scroll position is
> expressed in pixels, and the new font may be sometimes much smaller than
> the old one.
>
> I think the scroll position update code belongs to ME_SetCharFormat, and
> should be added there in a separate patch. Compare WM_SETFONT to
> EM_SETCHARFORMAT and you'll know why.

Sounds good to me. When it is implemented, I'll add a conformance test
for the scrolling behaviour, too.

> The plan is: if my original patch gets accepted, then you can extract
> the testing code and WM_GETFONT handler which is missing in my
> implementation and send it as a separate patch. This will avoid the mess
> related to combining those two patches into one.

MMkay. Will do!

> When this stuff is finished, I'd suggest you try implementing the
> ES_PASSWORD-related stuff, combined with WM_SETFONT handling it would
> let us fix a couple Bugzilla reports :) It should be pretty
> straightforward and independent of other parts of the code. And I'm not
> going to touch that stuff now.

Most Excellent. ES_PASSWORD (actually I wrote about a third of it
already) is only supposed to affect single-line controls, but I could
always just implement it for all rich edit controls, and that'll right
itself when single-line is implemented. That would probably make more
sense, as I doubt anything relies on the "Does nothing if it's not a
single-line control" behaviour.

Actually, after implementing that there's a bunch of styles I could
add somewhat easily, like WS_SETFONT.

Thanks for the help / I'll let ya know what I'm working on.
--Matt