- Forum
- Windows Programming
- Child Window with Child Scrollbars
Child Window with Child Scrollbars
Little by little, this project is coming together. I now wish to use child scrollbars to scroll a child window. Can anyone explain this procedure? I have already created child windows, and child scrollbars. I was just wondering how to link them. I am assuming that this involves the "SendMessage()" function. Or, does this involve subclassing?
I should note, that I wish to use two child windows. The vertical scrollbar will control both children simultaneously. However, each child will have its own horizontal scroll.
For the moment though, I would like to try a simple exercise. I want to create a child window that displays an image. There is one child scrollbar for the horizontal, and one for the vertical. Just a simple explanation of the procedure should do, as I have already worked with these individual components (loading images, child windows, child scrollbars, etc).
On a somewhat related topic, can the thumbs of child scrollbars be made "proportional".
I should note, that I wish to use two child windows. The vertical scrollbar will control both children simultaneously. However, each child will have its own horizontal scroll.
For the moment though, I would like to try a simple exercise. I want to create a child window that displays an image. There is one child scrollbar for the horizontal, and one for the vertical. Just a simple explanation of the procedure should do, as I have already worked with these individual components (loading images, child windows, child scrollbars, etc).
On a somewhat related topic, can the thumbs of child scrollbars be made "proportional".
Last edited on
I could help you with that too anachronon, but I'm still working on the tutorial about dynamic multi-dimensional arrays. I've posted a lot of it in your subclassing post, as I can't start new topics in this forum - only reply to other's posts like I'm doing now. When I get it all done I believe I'll post it too on my board at another forum, as nobody will find it here under a subclassing topic.
I will write a sentence or two on your scrolling though. Your parent window acts as a viewport of a larger child window containing your graphics. Say you have a 600X600 pixel parent window, and the child of the parent is 1200X1200 pixels. Windows will automatically/transparently clip the child so you will only see a bit less than 600X600 pixels of it. In your WM_HSCROLL and WM_VSCROLL message handlers you use MoveWindow() to move the child which reveals parts hidden previously by the parent.
I will write a sentence or two on your scrolling though. Your parent window acts as a viewport of a larger child window containing your graphics. Say you have a 600X600 pixel parent window, and the child of the parent is 1200X1200 pixels. Windows will automatically/transparently clip the child so you will only see a bit less than 600X600 pixels of it. In your WM_HSCROLL and WM_VSCROLL message handlers you use MoveWindow() to move the child which reveals parts hidden previously by the parent.
It only took me a couple minutes to find one of my 'proof of concept' test apps from around 2012 and test check it for build-ability under VC2019 under x86 and x64. At that time I was mostly using GCC. In any case, here is ScrollControls.cpp and ScrollControls.h. You'll need to adapt the code to scroll your graphics - this app scrolls child window button, label, and edit controls on a 'pane' child of the main parent. First, ScrollControls.h....
|
|
Last edited on
|
|
Hey Freddie1. Thanks for that. I think I might have a handle on what I am trying to do. I was working earlier today on the child window of my test. I have that up and running. Tomorrow, I will try messing with the child scrollbars.
I do have a couple specific questions on your code. I'll try to address them one at a time. My first question is on this line of code:
I see that you are using it to get the handle of the child window. How does the program know which child? What if there is more than one child, that you wish to get a handle?
I do have a couple specific questions on your code. I'll try to address them one at a time. My first question is on this line of code:
|
|
I see that you are using it to get the handle of the child window. How does the program know which child? What if there is more than one child, that you wish to get a handle?
There are two Window Classes Registered in the program; a "ScrollControls" Class registered in WinMain(), and a "Pane" Class Registered in fnWndProc_OnCreate(). When the CreateWindow() call was made in fnWndProc_OnCreate() to create one instance of the "Pane" class, the parent of this instance was set to the instance of the main or "ScrollControls" window, and the HWND returned from the CreateWindow() call was stored in the WNDCLASSEX::cbWndExtra bytes of that main program or app window by a call to SetWindowLongPtr(). In other words, or in OOP speak, it became a member variable of a parent class. The 'Getters' and 'Setters', or, in more OOP speak, 'mutators' of the class instance, in C based OOP, are GetWindowLongPtr() and SetWindowLongPtr(). An alternate way of doing this would be with GetProp() and SetProp(). For whatever personal reason, my habit is to use the GetWindowLong/SetWindowLong() approach.
Note that the HWND hPane variable was a local/stack based 'automatic' variable in fnWndProc_OnCreate() and fell out of scope when that function returned. However, it was needed again in another critical function - fnWndProc_OnVScroll(). It was needed there because a MoveWindow() call needed to be made on that window to cause the program to scroll. I was able to get it there where it was needed because I 'persisted' the value of the variable, as mentioned just above, in the WNDCLASSEX::cbWndExtra bytes.
Your question, "How does the program know which child?", I'm not sure I fully understand your question. There is only one instance of the "Pane" class in the program. The main window only has one child, which is the "Pane" window we are discussing. And the numeric value of its HWND is the only value stored or persisted in the main window's WNDCLASSEX::cbWndExtra bytes.
There are quite a few other child windows in the program, all of which are standard Windows Controls, i.e., static, edit, and button controls. These are all childs of the "Pane" window. None of them were ever used in the program. One can think of them as 'grandchildren' of the app's main window if one would like.
By the way, recall I stated I don't use global variables in my programs? Of course, this one doesn't have any. Neither does the one I posted for Malbor in that post of his. Its really not that hard to do. If you look at all my CreateWindow() calls in fnWndProc_OnCreate() for the child window controls you'll see I essentially threw away all the HWNDs returned by the CreateWindow() calls. In fact, strictly speaking, I would not have even needed to declare a hCtrl variable there - it was never used for anything, and I could have made bare CreateWindow() calls without having the function assign it to a variable at all! How so?
Because Windows, being the good behaving operating system that it is, keeps close track of every window created, every process, so on and so forth, within internal structures which it meticulously maintains, and will return that information to you with a simple function call asking for it. Note in ScrollControls.h I have #define statements where I assigned Control IDs for every child window to b e created. These serve as '
proxies' for the HWNDs of the controls/objects. They are one of the parameters of the CreateWindow() call (the HMENU parameter), and Windows internally keeps track of them. Windows will return the HWND of any object if you tell it to in a GetDlgItem() call where you specify the parent of the window and the Control ID of the window. That was never needed in this program because there is no coding for any of the controls; they were just put there so one could see them scroll.
This is kind of 'deep' but important stuff. That's why I'm mentioning it.
Note that the HWND hPane variable was a local/stack based 'automatic' variable in fnWndProc_OnCreate() and fell out of scope when that function returned. However, it was needed again in another critical function - fnWndProc_OnVScroll(). It was needed there because a MoveWindow() call needed to be made on that window to cause the program to scroll. I was able to get it there where it was needed because I 'persisted' the value of the variable, as mentioned just above, in the WNDCLASSEX::cbWndExtra bytes.
Your question, "How does the program know which child?", I'm not sure I fully understand your question. There is only one instance of the "Pane" class in the program. The main window only has one child, which is the "Pane" window we are discussing. And the numeric value of its HWND is the only value stored or persisted in the main window's WNDCLASSEX::cbWndExtra bytes.
There are quite a few other child windows in the program, all of which are standard Windows Controls, i.e., static, edit, and button controls. These are all childs of the "Pane" window. None of them were ever used in the program. One can think of them as 'grandchildren' of the app's main window if one would like.
By the way, recall I stated I don't use global variables in my programs? Of course, this one doesn't have any. Neither does the one I posted for Malbor in that post of his. Its really not that hard to do. If you look at all my CreateWindow() calls in fnWndProc_OnCreate() for the child window controls you'll see I essentially threw away all the HWNDs returned by the CreateWindow() calls. In fact, strictly speaking, I would not have even needed to declare a hCtrl variable there - it was never used for anything, and I could have made bare CreateWindow() calls without having the function assign it to a variable at all! How so?
Because Windows, being the good behaving operating system that it is, keeps close track of every window created, every process, so on and so forth, within internal structures which it meticulously maintains, and will return that information to you with a simple function call asking for it. Note in ScrollControls.h I have #define statements where I assigned Control IDs for every child window to b e created. These serve as '
proxies' for the HWNDs of the controls/objects. They are one of the parameters of the CreateWindow() call (the HMENU parameter), and Windows internally keeps track of them. Windows will return the HWND of any object if you tell it to in a GetDlgItem() call where you specify the parent of the window and the Control ID of the window. That was never needed in this program because there is no coding for any of the controls; they were just put there so one could see them scroll.
This is kind of 'deep' but important stuff. That's why I'm mentioning it.
Thanks Freddie1. Really, it wasn't that "deep". I did miss a couple things, while studying your code. I didn't notice that "ScrollControls" was declared as your main window class. That threw me. I was also a bit confused by the multiple uses of "GetWindowLong()". If the second parameter is "0", then the function retrieves what has been stored as "extra". Pre-defined macros in the second parameter cause the function to return info about the window.
What also confused me, was how "hwnd" is used in every callback function. I forgot that "hwnd" was a local variable in every one of those functions. So, I got confused, as to which window was being called. I think in my code, I will need to use different names, to make it more clear.
The "GetDlgItem()" function may be what I am looking for. I don't know yet. I'll have to give it a try. I know I'll have more questions.
What also confused me, was how "hwnd" is used in every callback function. I forgot that "hwnd" was a local variable in every one of those functions. So, I got confused, as to which window was being called. I think in my code, I will need to use different names, to make it more clear.
The "GetDlgItem()" function may be what I am looking for. I don't know yet. I'll have to give it a try. I know I'll have more questions.
Say, anachronon, if I don't answer any posts for a couple days it'll be because I'm may be having laptop problems. I think the hard drive may be going on the only box I'm able to get on the internet with. I'm hoping I can make it to Tuesday, cuz I gotta go up to Pueblo, CO then, and I'll get a new laptop. Geez, I only got 4-1/2 years outta this one. Last HP I had I got 13 years outta it! Hopefully it'll keep goin 'till then!
Fred
Fred
Topic archived. No new replies allowed.