On Wed, Jul 2, 2008 at 1:31 PM, Alex Villacís Lasso a_villacis@palosanto.com wrote:
Alex Villacís Lasso escribió:
This is supposed to be a fix for bug #12311 . This bug involves a recursive message loop where the application forces visibility of scrollbars for the richedit control, which causes a WM_SIZE that triggers an update of the window size and re-hiding of the scrollbar. However, just after exiting the richedit winproc, the app forces visibility again, which again triggers a WM_SIZE, and so on. Native is oblivious to the fact that an external agent is messing with the scrollbar visibility, and is therefore unaffected by recursion. This patch attempts to fix this behavior in builtin and test for it. I have tried to test it on WinXP-SP2 and Win98, but testing on other platforms is helpful too.
Changelog:
- Use internal copy of scrollbar state instead of directly reading
state from scrollbars, just as native does.
- Tests for ability to externally modify scrollbars.
- Test for behavior that caused recursion until builtin richedit was
fixed.
Nobody has commented on this patch. Is this the wrong strategy to solve the problem? Or are tests failing in some other platform? Copy of patch at bug #12311 with downloadable app to test.
I am wondering if the following is related.
Repeat the following steps with native and buildin wordpad: 1. Open up Wine's word 2. Type/Paste in a lot of lines of text 3. Put the cursor at the end of the text 3. Now increase the height of the window, but not to the point where all the text is shown and the scrollbar disappears.
With native richedit you will notice the text stays in place and more space will appear at the bottom past the end of the text.
With builtin richedit you will notice that the text will be scrolled down.
This might show that the scroll position is stored for the richedit control but it might also show that there are differences as to how WM_SIZE is handled which lead to the bug.
I haven't looked into it enough to figure it out, but I hope that helps.