On 6/25/06, Krzysztof Foltman wdev@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.
- 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.
- Your code ignores lParam (which is supposed to specify if it
repaints immediately)
Ahh. Missed that somehow.
- 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)
- 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