On 6/25/06, Krzysztof Foltman <[EMAIL PROTECTED]> 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
