On 6/25/06, Krzysztof Foltman <wdev(a)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