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