Uploaded image for project: 'Core ReactOS'
  1. Core ReactOS
  2. CORE-19669

Issues with CS_HREDRAW | CS_VREDRAW and scrollbars

    XMLWordPrintable

Details

    Description

      Hello,

      I'm developing an application that targets ReactOS as a supported platform, and I've hit a bit of a problem with the system-provided scrollbar (vertical in my case, WS_VSCROLL).

      I have the window class styles CS_HREDRAW | CS_VREDRAW configured for my window, which means that any window size change should be followed by an invalidation of the entire screen contents, triggering WM_PAINT.  This works correctly for manually resizing the window, but when the system-provided scrollbar disappears or re-appears in response to a SetScrollInfo() call, I do get a WM_SIZE message, but not a WM_PAINT message.

      Here is how it behaves, this is the default state of my application (the hebrew text is merely there to test mixed-direction text):

      When I subsequently add enough text to fill the window and make the vertical scroll bar appear, e.g. by pressing the F1-F5 keys, the vertical scroll bar appears, but as you can see, it overlaps some text which should've been redrawn:

      Here is how it looks after minimizing and maximizing the window (dragging it off-screen and bringing it back yields the same result):

      Now, if I remove some text by selecting a paragraph that spans multiple messages and press F7, the scroll bar disappears, and leaves behind some old screen data:

      Again, triggering WM_PAINT by invalidating the corrupted areas fixes it up.

      Since the line wrapping is performed in WM_SIZE, and merely triggering WM_PAINT fixes the issue, the problem appears to be that WM_PAINT does not get sent when the scrollbar disappears/reappears, but WM_SIZE does.
      I've also tested this program on Windows 2000, Windows XP, and Windows 10, and there, I do get a WM_PAINT message when the scroll bar's visibility status changes.
      I did test this on the latest nightly, you can see the version string in the screenshots, it is 0.4.15-dev-8260-gedf6b80-x86-gcc-lin-dbg.

      I'm including the test program in the attachment, dopl2_win32_tw_cmd_demo-1.exe, along with source code, vscroll-appear-bug-1.zip.  It's still a work in progress, so it might be buggy in its own right, the F1-5 keys generate messages, the F6 key appends text to a selected message, and F7 key replaces the text of a selected message with a short string.

      Best Regards,
      Marek

      Attachments

        Issue Links

          Activity

            People

              DougLyons DougLyons
              dusxmt dusxmt
              Votes:
              2 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: