GaryC
asked on
Info about Scrollbars..
A window can have scrollbars if the appropriate style bits are set. As it is scrolled, WM_VSCROLL and WM_HSCROLL messages are sent to the window. If I look at it with Spy++, I don't see any child windows (the scrollbars) I am making a fully user drawn window and would like to have non-standard looking scrollbars without the hastle of creating them from scratch. Spy++ lists these additional Scrollbar messages..
SBM_ENABLE_ARROWS, SBM_GETPOS, SBM_GETRANGE, SBM_GETSCROLLINFO, SBM_SETPOS, SBM_SETRANGE, SBM_SETRANGEREDRAW, SBM_SETSCROLLINFO
I suppose that I thought the scrollbars would be child windows that get these messages and would in turn send the WM_VSCROLL messages to it's parent. I can't seem to get Spy++ to log a single SMB_ message.
So what's the deal? I would ideally like to get device contexts to the different components of the scrollbar such as the thumb, slide and buttons. That way, I could draw them to match my form but keep the normal functionality.
Is this possible?
SBM_ENABLE_ARROWS, SBM_GETPOS, SBM_GETRANGE, SBM_GETSCROLLINFO, SBM_SETPOS, SBM_SETRANGE, SBM_SETRANGEREDRAW, SBM_SETSCROLLINFO
I suppose that I thought the scrollbars would be child windows that get these messages and would in turn send the WM_VSCROLL messages to it's parent. I can't seem to get Spy++ to log a single SMB_ message.
So what's the deal? I would ideally like to get device contexts to the different components of the scrollbar such as the thumb, slide and buttons. That way, I could draw them to match my form but keep the normal functionality.
Is this possible?
To do your own scrollbars, you have two choices.
You can continue with the windows design and not make your non-standard scroll bars child windows. To do this you would paint them when you pain the non-client area of the window, or when scrolling messages occur.
Or you can go with a bit "structured" design and make the scroll bars child windows. (Which will be drawn when they get WM_PAINT messages). If you go this route however, you will need to handle "communication" between the scroll bars controls and the window they belong to. That is when they are scrolled they will need to send scroll messages to their parent.. (Also when the parent's information changes in size it needs to notify them.) (one dissadvatage to this approach is that the scrollbars will be located in the client area--child windows cant be in the non-client area--this may make positioning/drawing calculations a little tougher.
Let me know if you have questions.
You can continue with the windows design and not make your non-standard scroll bars child windows. To do this you would paint them when you pain the non-client area of the window, or when scrolling messages occur.
Or you can go with a bit "structured" design and make the scroll bars child windows. (Which will be drawn when they get WM_PAINT messages). If you go this route however, you will need to handle "communication" between the scroll bars controls and the window they belong to. That is when they are scrolled they will need to send scroll messages to their parent.. (Also when the parent's information changes in size it needs to notify them.) (one dissadvatage to this approach is that the scrollbars will be located in the client area--child windows cant be in the non-client area--this may make positioning/drawing calculations a little tougher.
Let me know if you have questions.
ASKER
I have no other option to select (outside of accepting) then reject and that word seems so harsh. I appreciate the input.
Yep, I know about scrollbar controls. I'm dealing with the scrollbars that are "attached" to a window as definded in it's style bits. I may or maynot be writing the code to link a scrollbar to a view. I want my app to be able to subclass any of my forms however they were made so that I don't have to recreate the wheel for all the possible forms. In theory, I would be able to hook into the message loop and draw what I want. It's easy to do with the non-client area but i'm baffled with the scrollbars. When I redraw, how do I know where to draw the thumb? What processes the hit test to know what part of the scroll bar was hit?
Yep, I know about scrollbar controls. I'm dealing with the scrollbars that are "attached" to a window as definded in it's style bits. I may or maynot be writing the code to link a scrollbar to a view. I want my app to be able to subclass any of my forms however they were made so that I don't have to recreate the wheel for all the possible forms. In theory, I would be able to hook into the message loop and draw what I want. It's easy to do with the non-client area but i'm baffled with the scrollbars. When I redraw, how do I know where to draw the thumb? What processes the hit test to know what part of the scroll bar was hit?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> What processes the hit test to know what part of the scroll bar was hit?
I'm not sure what you mean. You will process the WM_HSCROLL AND WM_VSCROLL to scroll your client are to a new position. I.e. you will do scroll specific information in those message handles. Ussually you will calculate and record the new position and then just invalidate the client area so that the next WM_PAINT draws things in the new scroll position.
I'm not sure what you mean. You will process the WM_HSCROLL AND WM_VSCROLL to scroll your client are to a new position. I.e. you will do scroll specific information in those message handles. Ussually you will calculate and record the new position and then just invalidate the client area so that the next WM_PAINT draws things in the new scroll position.
What is happening with this queston? Do you still need help?
Still there? Still need help?
continues.