comctl32/listview: update dwStyle before checking for scrollbar

Daniel Jelinski djelinski1 at gmail.com
Sat Sep 22 14:38:52 CDT 2012


2012/9/22 Nikolay Sivov <nsivov at codeweavers.com>:
> I see. Now a question is how scroll bars are enabled/disabled in a case
> you're trying to fix,
> and a message test should be added for listview after that. What I'm seeing
> - ControlSpy
> running on XP shows style change messages after I toggle scrollbar bits, but
> we don't have its source so
> who knows what it does.

Do you toggle these bits using SetWindowLong or SetScrollInfo? Wine
uses SetScrollInfo, which is probably the reason why we don't get
these messages.

My first try at this bug was updating cached dwStyle in LISTVIEW_UpdateScroll:
http://source.winehq.org/source/dlls/comctl32/listview.c#L2058
However, that was not sufficient for a sample application I created in
Delphi - seems that Delphi creates the scrollbar elsewhere.

Probably the code could be rewritten to not depend on WS_HSCROLL and
WS_VSRCOLL being correct:
http://source.winehq.org/source/dlls/comctl32/listview.c#L10881 is the
only line that depends on it.

> And apparently we have code in WM_STYLECHANGED handler to deal with scroll
> bars:
>
> ---
>     if (((lpss->styleOld & WS_HSCROLL) != 0)&&
>         ((lpss->styleNew & WS_HSCROLL) == 0))
>        ShowScrollBar(infoPtr->hwndSelf, SB_HORZ, FALSE);
>
>     if (((lpss->styleOld & WS_VSCROLL) != 0)&&
>         ((lpss->styleNew & WS_VSCROLL) == 0))
>        ShowScrollBar(infoPtr->hwndSelf, SB_VERT, FALSE);
> ---
>
> these lines were edited 10 years ago last time, sure it could be a noop
> but that raises a question why it's here.

Dead code. I meant to remove these in the next patch, since there are
no bugs against scrollbars in listview. I guess user32 was way less
capable back then.

Regards,
Daniel



More information about the wine-devel mailing list