my wndProc is out of scope

**FillYourBrain** · 06-23-2004

Originally Posted by Raison

I read it in a book that i should not call the window function directly (e.g. return mf->wndProc(hwnd,message,wParam,lParam); ) because

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.

**Raison** · 06-23-2004

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.

**FillYourBrain** · 06-23-2004

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.

**Raison** · 06-23-2004

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?

**FillYourBrain** · 06-23-2004

Originally Posted by Raison

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.

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

**Raison** · 06-23-2004

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.

so when do i actually need to use CallWindowProc and SendMessage. Now i even begin to wonder what difference they have.

**FillYourBrain** · 06-23-2004

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.

**Raison** · 06-23-2004

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?

**FillYourBrain** · 06-23-2004

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.

**Raison** · 06-23-2004

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.

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.

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.

**FillYourBrain** · 06-23-2004

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.

**Ken Fitlike** · 06-23-2004

Originally Posted by Raison

The whole idea of using SetWindowLong n GWL_USERDATA is to subclass so that i can use my non-static wndProc as the window processing function. All msg to handled by the non-static wndProc is directed to it by staticWndProc,else DefWindowProc handles it. But why is it not good to use my static window procedure (skeleton::staticWndproc) as the window procedure when i registered my window class. Sorry, i am a slow learner. Could u explain more about what u mean?

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.

**FillYourBrain** · 06-23-2004

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

**Raison** · 06-23-2004

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.

**FillYourBrain** · 06-24-2004

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.