Major tidy up of Scroll.c to add foundations for flatscroll bars

Andrew M. Johnston johnstonam at logica.com
Tue Oct 8 00:14:13 CDT 2002


On Tue, 8 Oct 2002 01:38, Alexandre Julliard wrote:
> All the flat scrollbar stuff has nothing to do in scroll.c, the normal
> scrollbars shouldn't need to know anything about flatsb at all. The
> flatsb control should intercept messages it needs to change by
> subclassing the windows, and call down to the normal scrollbar where
> necessary.

The problem with this approach are
1. The scroll code has entry points not from the api (e.g from Nonclient)
2. The scroll code calls the critical functionality (drawing) in several different
   ways and different different places
3. In tracking there is a need to hold some state not in the info structure between api calls
   If there are two pieces of drawing code (one in scroll.c and another in flatsb.c) then either
   this state has to be communicated or the state and the code that manipulates it needs to be
   duplicated.
4. The flatSB and non flat scroll bars return different thumb position values in some instances
    due to the settings of the thumb and arrow size.

With these observations in mind,  I think the suggested approach becomes

1. Remove the non api entry points into scrollbar,  the first patch I sent does this for mdi
    But another is needed for nonclient.c
2. Make all the drawing paths use paint messages internally so they can be picked up by the
   subclassed window when it is a flatSB.
3. Implement flatSB by subclassing the window and process the WM_PAINT messages differently
  
Some more thought is needed to work out how to handle the thumb position interaction,
but a valid solution would be to duplicate the code, tweeking for the minor differences.

Although this is the logical order, the order that I will try and send patches will be slightly different
as changing the non client code to message based as the scroll code stands at the moment needs
significant effort.  Rather the order will be

1. apply the patch to mdi,
2. send three medium patches that simplify the scroll drawing and message processing paths
3. send a patch that makes non clients send messages to the scroll bars.
4. make flat scroll bars use window sub classing and implement the drawing and thumb control code.

I expect a far amount of duplication in falt scroll bars particularly of the functions called
SCROLL_GetThumb
SCROLL_GetScrollBar
SCROLL_DrawScrollBar




More information about the wine-devel mailing list