Re: Major tidy up of Scroll.c to add foundations for flatscroll bars
"Andrew M. Johnston" <johnstonam(a)logica.com> writes:
controls.h - improve the scroll bar nonclient separation nonclient.c - remove NC_TrackScrollBar and use scrollbar WINAPI routine scrollbar.c - complete rewrite using similar structure and logic - unified drawing code - simpler event processing logic - minimised drawing - better conformance to windows on LINEUP and LINEDOWN events
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.
Note: it is possible to split the scroll changes up into three consistent parts if really necessary
That would be nice. Also if you could avoid unnecessary changes like renaming SCROLLBAR_INFO to SCROLL_INFO that would make it easier to see what is really being changed. -- Alexandre Julliard julliard(a)winehq.com
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
"Andrew M. Johnston" <johnstonam(a)logica.com> writes:
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
The thing is we cannot pick any implementation we like, we have to do it the Windows way. So using messages internally is only acceptable in cases where Windows does it that way. The native flatsb code has to work on top of our scrollbars, and our flatsb implementation should work on Windows too. -- Alexandre Julliard julliard(a)winehq.com
On Wed, 9 Oct 2002 00:37, Alexandre Julliard wrote:
The thing is we cannot pick any implementation we like, we have to do it the Windows way. So using messages internally is only acceptable in cases where Windows does it that way.
If the native comctl is used then some (but not all) of the drawing of the control is done but it ignores the flat scroll properties. This may be due to using internal redraw paths rather than the correct ones. I am in the process of investigating further.
The native flatsb code has to work on top of our scrollbars, and our flatsb implementation should work on Windows too.
Ah, the second part indicates where additional confusion arose. I thought user.dll was one of the core dlls that could can never be native. Are there plans to use comctrl on native windows? Since I was assuming that user.dll could not be native and wine's native dlls would not be used on native user dll then it seemed reasonable to extended the user code to implement both types and make flatsb defer to this code.
On October 9, 2002 06:19 am, Andrew M. Johnston wrote:
Ah, the second part indicates where additional confusion arose. I thought user.dll was one of the core dlls that could can never be native. Are there plans to use comctrl on native windows?
Yes, Wine will not run Windows' USER.DLL, but being able to run native comctrl on Wine, *and* run Wine's comctrl on Windows is important. -- Dimi.
"Andrew M. Johnston" <johnstonam(a)logica.com> writes:
Ah, the second part indicates where additional confusion arose. I thought user.dll was one of the core dlls that could can never be native. Are there plans to use comctrl on native windows?
Yes, that can be useful for testing; and it will definitely be used on platforms like ReactOS that don't have our user.dll. -- Alexandre Julliard julliard(a)winehq.com
participants (3)
-
Alexandre Julliard -
Andrew M. Johnston -
Dimitrie O. Paun