The book was talking about the WNDPROC which is static in your case. You aren't calling the static WNDPROC directly when you call the virtual one.Originally Posted by Raison
The book was talking about the WNDPROC which is static in your case. You aren't calling the static WNDPROC directly when you call the virtual one.Originally Posted by Raison
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
Sorry about this but i dont understand. That means in my case, i cannot call the static wndProc directly in the static wndProc function itself? I'm lost.
what the book was likely suggesting is...
lets say you want to tell a window that you want it to repaint. You think that you can call the window function with a WM_PAINT message but you can't because it wont work.
or maybe you want to do some processing that happens when the thing is sized, so you call it with a WM_SIZE message.
These are the things you shouldn't do. Don't call it directly.
As for inside of the static or global WndProc function itself, you can certainly call other functions. Your virtual wndProc is not a WNDPROC at all, but a method on the class. Therefore you can most definitely call it explicitly.
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
ok thanks for helping me out so far. I still have alot of doubts:
You mean like if i want to resize the window using its wndProc. I should not call it explicitly, but instead i should use CallWindowProc?
But i tot i should use SendMessage in this case. Then when should i use CallWindowProc?
you won't be able to do it that way anyway, but its just an example. Just don't call it directly. don't worry too much about why. Windows just wants to be the only one to call it.Originally Posted by Raison
The real matter here is that your virtual wndProc is not a WNDPROC so you can call it. Change the name if you want it to be less confusing
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
so when do i actually need to use CallWindowProc and SendMessage. Now i even begin to wonder what difference they have.you won't be able to do it that way anyway, but its just an example. Just don't call it directly. don't worry too much about why. Windows just wants to be the only one to call it.
You shouldn't really use CallWindowProc except in the example where you are forwarding a WNDPROC's parameters to another WNDPROC. It comes into play in subclassing.
SendMessage and PostMessage are used to throw a message at a window from who knows where.
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
I know all windows of the same class share the same wndProc which in my case is the staticWndproc(). Suppose one of the window of that class has that original wndProc replaced by another static wndProc say nextStaticWndProc().
Senario 1:
(THIS IS THE SUBCLASSING I KNOW WHERE I HAVE TO USE CALLWINDOWPROC)
In nextStaticWndProc(), if i intend to pass any message not processed to the original staticWndproc(), I must use CallWindowProc() and not call the staticWndproc() directly. Am i right?
Senario 2:
In nextStaticWndProc(), if i intend to pass any message not processed to the another g_WndProc() i defined globally, I can call the g_Wndproc() directly. Am i right?
scenario 1 absolutely correct
scenario 2. Well, not sure why you would do this, but yeah. Really, for the world of OOP, you probably want to forward it into a class and abandon the whole WNDPROC methodology. MFC uses a MESSAGE_MAP to hide the WNDPROC and make the message handling into a series of handler methods. Something like that is ultimately what you want. In truth, the WNDPROC methodology is clunky and difficult. The reason they tell you not to call it is not because it is some sort of magical function that is somehow different than other functions. They tell you not to call it directly because windows has some default activity that is supposed to happen on these calls. It can't be made to happen if you call it directly.
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
i asked about senario 2 because i want to know if "not calling the wndProc directly" mean dont call the wndProc originally registered with the class directly. Any additional wndProc defined subsequently can be called directly.
But from what u said,i cant help thinking it imply that i should call wndProc using CallWindowProc as far as possible. But in my case, mf->wndProc is a virtual function which cant be called using CallWndProc. So i can call it directly because i have no choice.In truth, the WNDPROC methodology is clunky and difficult. The reason they tell you not to call it is not because it is some sort of magical function that is somehow different than other functions. They tell you not to call it directly because windows has some default activity that is supposed to happen on these calls. It can't be made to happen if you call it directly.
your virtual wndProc is again, NOT a WNDPROC. WNDPROCs are a type of function that is passed to windows as an "entry point" to your application. It is a place for windows to give you messages. your virtual wndProc, while named wndProc is no such thing.
Therefore it is not an exception to the rule as it is completely outside of the rule.
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
Sorry, I misread what you had, despite quoting your comment. I had read it as 'GWL_WNDPROC' instead of 'GWL_USERDATA' - fortunately FYB was on hand to keep things relevant; please ignore my earlier remark and forgive any confusion I've caused.Originally Posted by Raison
CProgramming FAQ
Caution: this person may be a carrier of the misinformation virus.
Not listening is one of my bigger flaws too.
We all know that you know what you're talking about in regard to windows API programming.
ken f is one of the better sources around here Raison
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
Alot of the time, i know how things should be done in win api but dont know not why.
I'm sorry i keep thinking that my virtual wndProc is not a wndProc, FYB.
So let me try to define a wndProc:
Is it any callback function registered in a window class or set under SetWindowLong n GWL_WNDPROC? So in the case of setWindowLong:
WNDPROC origWndProc = SetWindowLong(hwnd,GWL_WNDPROC,wndProc);
origWndProc still remains as a wndProc. That's why i must call it using CallWindowProc?
There must be some internal processes that happen when i register a wndProc in a window class or set it in a window using SetWindowLong that i am not aware of. That's i kept thinking my virtual wndProc is considered a wndProc.
In fact, since it is not a wndProc, i dont even have to make my virtual wndProc a CALLBACK function. From what i know, CALLBACK function r functions that WINDOWS call on its own.
I tried that in my program and it worked.
when you subclass, you are trying to override some default behavior of the window. But not all. You still want the thing to work right. For instance, suppose you subclass the button window class. You still want it to work like a button right? that behavior is in the original WNDPROC. So that's why you want to call it. But you need to use CallWindowProc anyway, to make sure Windows gets to do the things that are necessary before and after a WNDPROC gets called. The things that windows does are implementation details that we may never know.
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter