Window Subclassing?
in [Visual C]
|
Prev: Embedded VC++ Developers needed
Next: Shell_TrayWnd
From: Robby on 24 Feb 2006 14:01 Hello , For the persons that have been usually helping me through Petzold's book, I have another question regarding COLORS1 sample program. I must admit, I am having more difficulty fully understanding everything that is going on in this program than usual. I have to say, For myself, Petzold is constantly exposing me to brand new material and techniques which I have never heard of or done before. I find the learning curve quite steep. Thanks for your patients. I have already posted a question for COLORS1 about the SetWIndowLong in which the news groups have gracefully answered. So if I may..... I will start with my second question regarding COLORS1 which incorporates a technique called Window SubClassing. The following line: OldScroll[i] = (WNDPROC) SetWindowLong(hwndScroll[i], GWL_WNDPROC, (LONG) ScrollProc); as Petzold explains it as so: "Now the function ScrollProc gets all messages that Windows sends to the scroll bar window procedure for the three scroll bars in COLORS1" So I guess the SetWindowLong function changes an attribute of the specified window which in this case sets a new address of ScrollProc to the lpfnWndProc attribute of every scrollBar window control. (I don't know if I said this right!!!!!!!!) And so this is what we call Window Subclassing... right. If we back track a little...regarding the way Checker3 sample program is done on p.298 of Petzold's book... the ChildWndProc is defined in Win main and then registered ....right, and also we have a ChildWndProc function of CALLBACK type.... right, so given that it seems very similar as the COLORS1, my question is, is the Checkers3 sample program using Window subclassing aswell? Basically, I see that CECKER3 and COLORS1 both have an extra CALLBACK function and only COLORS1 talks about Window Subclassing. I was wondering if CHECKER3 is also using window Subclassing but in a different way! and if so, why is the return in CHECKER3 a DefWindowProc as so: return DefWindowProc(hwnd,message,wParam,lParam); and in COLORS1 its CallWindowProc as so: return CallWindowProc(OldScroll[id],hwnd,message,wParam,lParam); Another thing!!!! why is it that when I look up for help on a function.... lets take SetWindowLong for example... and it says: "This function has been superseded by the SetWindowLongPtr function. To write code that is compatible with both 32-bit and 64-bit versions of Microsoft® Windows®, use the SetWindowLongPtr function." Well, why is it that SetWindowLong still works with the examples I am currently doing. I am using 32 bit am I? and still I don't use SetWindowLongPtr! All sugestions appreciated...... I will probably have another post regarding this sample.... unfortunately! -- Best regards Robert
From: William DePalo [MVP VC++] on 24 Feb 2006 14:39 "Robby" <Robby(a)discussions.microsoft.com> wrote in message news:7EAC6DC3-1F46-4952-B545-A0956EDF182B(a)microsoft.com... > The following line: > > OldScroll[i] = (WNDPROC) SetWindowLong(hwndScroll[i], > GWL_WNDPROC, (LONG) ScrollProc); > > as Petzold explains it as so: > "Now the function ScrollProc gets all messages that Windows sends to the > scroll bar window procedure for the three scroll bars in COLORS1" > > So I guess the SetWindowLong function changes an attribute of the > specified > window which in this case sets a new address of ScrollProc to the > lpfnWndProc > attribute of every scrollBar window control. (I don't know if I said this > right!!!!!!!!) > > And so this is what we call Window Subclassing... right. All windows of the same class behave in the same way because they share the same window procedure. Every time Windows sends a message to a window of the class, the same handler runs. For example all windows of the same class share the same paint procedure so that they get painted in the same way. (To be sure there may be some variance in behavior due to window "styles" which are or or not present, but that's a nit). The SetWindowLong() function changes an attribute of a window. When that attribute is the window procedure itself much can be changed. But subclassing is most often used when the developer wants much of the same behavior of a window class but not all of it. In that case he installs a new window procedure with specialized handlers for a handful of messages and which delegates the handling of the rest of the messages to the original window procedure. > Well, why is it that SetWindowLong still works with the examples I am > currently doing. I am using 32 bit am I? and still I don't use > SetWindowLongPtr! SetWindowLongPtr() is source compatible across 32 and 64 bit versions of Windows. What you are doing may break somthing on a 64 bit platform. Regards, Will
From: David Wilkinson on 24 Feb 2006 14:59 Robbie: Replies inline [snip] > So if I may..... I will start with my second question regarding COLORS1 > which incorporates a technique called Window SubClassing. > > The following line: > > OldScroll[i] = (WNDPROC) SetWindowLong(hwndScroll[i], > GWL_WNDPROC, (LONG) ScrollProc); > > as Petzold explains it as so: > "Now the function ScrollProc gets all messages that Windows sends to the > scroll bar window procedure for the three scroll bars in COLORS1" > > So I guess the SetWindowLong function changes an attribute of the specified > window which in this case sets a new address of ScrollProc to the lpfnWndProc > attribute of every scrollBar window control. (I don't know if I said this > right!!!!!!!!) > > And so this is what we call Window Subclassing... right. Yes. > If we back track a little...regarding the way Checker3 sample program is > done on p.298 of Petzold's book... the ChildWndProc is defined in Win main > and then registered ....right, and also we have a ChildWndProc function of > CALLBACK type.... right, so given that it seems very similar as the COLORS1, > my question is, is the Checkers3 sample program using Window subclassing > as well? No > Basically, I see that CECKER3 and COLORS1 both have an extra CALLBACK > function and only COLORS1 talks about Window Subclassing. I was wondering if > CHECKER3 is also using window Subclassing but in a different way! In Checker3 there are two types of window, and two different window procedures. Each type is created with the appropriate window procedure, and it is not subsequently changed. There is no subclassing. In COLORS1, the scrollbars are created using a standard Windows class, "scrollbar", which has a window procedure defined by Windows. When you subclass, you change this window procedure to your own. > and if so, why is the return in CHECKER3 a DefWindowProc as so: > > return DefWindowProc(hwnd,message,wParam,lParam); > > and in COLORS1 its CallWindowProc as so: > > return CallWindowProc(OldScroll[id],hwnd,message,wParam,lParam); When you write a window procedure, you only want to handle some of the messages; for the rest you are willing to accept the default Windows behavior. For a non-subclassed window, this is DefWindowProc. For a subclassed window, it is the original window procedure that you replaced, which may in turn call DefWindowProc. > > Another thing!!!! why is it that when I look up for help on a function.... > lets take SetWindowLong for example... and it says: > > "This function has been superseded by the SetWindowLongPtr function. To > write code that is compatible with both 32-bit and 64-bit versions of > Microsoft® Windows®, use the SetWindowLongPtr function." > > Well, why is it that SetWindowLong still works with the examples I am > currently doing. I am using 32 bit am I? and still I don't use > SetWindowLongPtr! Yes, you are compiling for 32-bit Windows. So you CAN use SetWindowLong. But if you want your code to compile for 64-bit Windows some time in the future, you should use SetWindowLongPtr. You can set your compiler to give warnings for code that is not 64-bit compatible. > All sugestions appreciated...... > I will probably have another post regarding this sample.... unfortunately! > Robbie, I have been meaning to ask you. I see you are spending a lot of time learning traditional Win32 API programming. Why are you not learning MFC? Everything is so much easier to do in MFC, because it handles a lot of details for you. In particular, subclassing is much, much, simpler because it is handled by ordinary C++ sub-classing. If you use MFC, it is useful (and sometimes necessary) to know how the API works, but you do not really need the detailed knowledge required to use it directly. And then there is .NET ... David Wilkinson
From: Robby on 24 Feb 2006 15:39 Hi David, I most thankyou for your post.... The reason I am learning Win32, is that eventually we are supposed to write an application in EVC++, but not on the Pocket PC or Mobile shells... In other words, all we want to buy is Windows CE (Windows that will be installed on a handheld) and write are application straight on the OS. Our application is one that must run very fast and efficiently. Last summer I put lots of time in C++, learning classes, arrays of classes, arrays of pointers, inheritance, even linked lists and much more ... and after that tried to learn EVC++ from Bolling's book (I hope I spelled his name right!) and I was completly lost. I did not even get passed chapter 2. Since I started Charles Petzold's book, I can't begin to tell you how informatve it is. He, and along with news groups (Thank god for you guys) I have been learning stuff that completely answers all of my questions about Boling's book. And not to mention, I am having lots of fun modifying Petzold's examples as I am learning this stuff. I really needed to learn WIN32 without any code polution before I can go onto EVC++. I figure I will finish Petzold's book by 2007, I hope!, its not an easy book to cross for a first time VC++ user like me. I don't know if I should still learn MFC at this point... I don't think that MFC would be adequate for doing programs on a handheld. If you would like, get back to me with your view on this! I love to talk about this stuff, I wish there would be a chat room where everyone can share programming experiences, details of solutions and so forth.... (I don't know if news groups has this, I never bothered to check)! Thanks for you concern! -- Best regards Robert "David Wilkinson" wrote: > Robbie: > > Replies inline > > [snip] > > > So if I may..... I will start with my second question regarding COLORS1 > > which incorporates a technique called Window SubClassing. > > > > The following line: > > > > OldScroll[i] = (WNDPROC) SetWindowLong(hwndScroll[i], > > GWL_WNDPROC, (LONG) ScrollProc); > > > > as Petzold explains it as so: > > "Now the function ScrollProc gets all messages that Windows sends to the > > scroll bar window procedure for the three scroll bars in COLORS1" > > > > So I guess the SetWindowLong function changes an attribute of the specified > > window which in this case sets a new address of ScrollProc to the lpfnWndProc > > attribute of every scrollBar window control. (I don't know if I said this > > right!!!!!!!!) > > > > And so this is what we call Window Subclassing... right. > > Yes. > > > If we back track a little...regarding the way Checker3 sample program is > > done on p.298 of Petzold's book... the ChildWndProc is defined in Win main > > and then registered ....right, and also we have a ChildWndProc function of > > CALLBACK type.... right, so given that it seems very similar as the COLORS1, > > my question is, is the Checkers3 sample program using Window subclassing > > as well? > > No > > > Basically, I see that CECKER3 and COLORS1 both have an extra CALLBACK > > function and only COLORS1 talks about Window Subclassing. I was wondering if > > CHECKER3 is also using window Subclassing but in a different way! > > In Checker3 there are two types of window, and two different window > procedures. Each type is created with the appropriate window procedure, > and it is not subsequently changed. There is no subclassing. > > In COLORS1, the scrollbars are created using a standard Windows class, > "scrollbar", which has a window procedure defined by Windows. When you > subclass, you change this window procedure to your own. > > > and if so, why is the return in CHECKER3 a DefWindowProc as so: > > > > return DefWindowProc(hwnd,message,wParam,lParam); > > > > and in COLORS1 its CallWindowProc as so: > > > > return CallWindowProc(OldScroll[id],hwnd,message,wParam,lParam); > > When you write a window procedure, you only want to handle some of the > messages; for the rest you are willing to accept the default Windows > behavior. For a non-subclassed window, this is DefWindowProc. For a > subclassed window, it is the original window procedure that you > replaced, which may in turn call DefWindowProc. > > > > > Another thing!!!! why is it that when I look up for help on a function.... > > lets take SetWindowLong for example... and it says: > > > > "This function has been superseded by the SetWindowLongPtr function. To > > write code that is compatible with both 32-bit and 64-bit versions of > > Microsoft® Windows®, use the SetWindowLongPtr function." > > > > Well, why is it that SetWindowLong still works with the examples I am > > currently doing. I am using 32 bit am I? and still I don't use > > SetWindowLongPtr! > > Yes, you are compiling for 32-bit Windows. So you CAN use SetWindowLong. > But if you want your code to compile for 64-bit Windows some time in the > future, you should use SetWindowLongPtr. You can set your compiler to > give warnings for code that is not 64-bit compatible. > > > All sugestions appreciated...... > > I will probably have another post regarding this sample.... unfortunately! > > > > Robbie, I have been meaning to ask you. I see you are spending a lot of > time learning traditional Win32 API programming. Why are you not > learning MFC? Everything is so much easier to do in MFC, because it > handles a lot of details for you. In particular, subclassing is much, > much, simpler because it is handled by ordinary C++ sub-classing. If you > use MFC, it is useful (and sometimes necessary) to know how the API > works, but you do not really need the detailed knowledge required to use > it directly. > > And then there is .NET ... > > David Wilkinson > > >
From: Robby on 24 Feb 2006 16:44 William, Thanks for your post! -- Best regards Robert "William DePalo [MVP VC++]" wrote: > "Robby" <Robby(a)discussions.microsoft.com> wrote in message > news:7EAC6DC3-1F46-4952-B545-A0956EDF182B(a)microsoft.com... > > The following line: > > > > OldScroll[i] = (WNDPROC) SetWindowLong(hwndScroll[i], > > GWL_WNDPROC, (LONG) ScrollProc); > > > > as Petzold explains it as so: > > "Now the function ScrollProc gets all messages that Windows sends to the > > scroll bar window procedure for the three scroll bars in COLORS1" > > > > So I guess the SetWindowLong function changes an attribute of the > > specified > > window which in this case sets a new address of ScrollProc to the > > lpfnWndProc > > attribute of every scrollBar window control. (I don't know if I said this > > right!!!!!!!!) > > > > And so this is what we call Window Subclassing... right. > > All windows of the same class behave in the same way because they share the > same window procedure. Every time Windows sends a message to a window of the > class, the same handler runs. For example all windows of the same class > share the same paint procedure so that they get painted in the same way. (To > be sure there may be some variance in behavior due to window "styles" which > are or or not present, but that's a nit). > > The SetWindowLong() function changes an attribute of a window. When that > attribute is the window procedure itself much can be changed. > > But subclassing is most often used when the developer wants much of the same > behavior of a window class but not all of it. In that case he installs a new > window procedure with specialized handlers for a handful of messages and > which delegates the handling of the rest of the messages to the original > window procedure. > > > Well, why is it that SetWindowLong still works with the examples I am > > currently doing. I am using 32 bit am I? and still I don't use > > SetWindowLongPtr! > > SetWindowLongPtr() is source compatible across 32 and 64 bit versions of > Windows. What you are doing may break somthing on a 64 bit platform. > > Regards, > Will > > >
|
Pages: 1 Prev: Embedded VC++ Developers needed Next: Shell_TrayWnd |