riched20: WM_SETFONT support

Krzysztof Foltman wdev at foltman.com
Sun Jun 25 02:11:30 CDT 2006


Matt Finnicum wrote:

> I was just about to send in the same patch when you did. I'll have to
> keep you updated on what I'm working on in the future.

That'd be nice - as I mostly stopped doing riched20 stuff for quite some 
time, and only got back to it a few days ago.

> I've attached the patch I was going to send - I suggest we use some
> parts of each (either I can merge them into a patch or you can, your
> call).

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.

> 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.

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

It does not, it assigns it to bRepaint and then uses in a condition. So 
it's a correct solution.

> 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.

> 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.

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.

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.

Krzysztof



More information about the wine-devel mailing list