General Windows questions

[NoCforMe]

I don't think I'm being "too complicated"; I just want to know the proper sequence of doing things when handling messages (and why), rather than just blindly copying code examples without really knowing what the hell is going on.

I think I've pretty much got it:

• When processing a message, return what the particular message (e.g., WM_PAINT) says to return. This seems to be generally zero. (At least on successful completion; there are always possible error conditions ...)
  
• For unprocessed messages, call DefWindowProc(). Don't set EAX on return from the window proc; just pass on the return value from DefWindowProc().
  
• DefWindowProc() can also be called before doing processing (as suggested by jj). I'm not sure exactly what cases one would want to do this in, though. More explanation, jj? (And someone else here contradicted this, saying you shouldn't call DefWindowProc() and do processing. So there seems to be some disagreement about this ...)
  

"Processing a message" is defined as calling into the Windows API in one's window proc.

So do you agree with this?

[petezl]

DefWindowProc isn't something that you normally think about when programming, its something entirely controlled by windows and we merely use it within the program skeleton. treat call def windows as the hole in the bottom of the bucket, ie none of your messages apply? then defWinProc!

Slightly different if you have subclassed something, in subclass code there is a need to call defWin specifically with CallWindowProc, [old handle]

some subclassing proc
Lousey key code:

Code Select Expand

.if al>="7"  ; then I want this,  no need to interfere, let windows process it
invoke CallWindowProc,OldWndProc,hEdt,uMsg,eax,lParam
ret
.endif

.if al==("V")   ; then I dont want this, so return false (windows dont get to hear about it)
xor eax, eax
ret
.endif

.if al==VK_RETURN   ; then I want this,  no need to interfere, let windows process it
invoke CallWindowProc,OldWndProc,hEdit,uMsg,wParam,lParam
ret
.endif

.else  ; none of the above apply? then we must return false
xor eax, eax
ret


Slightly less lousey code:
win proc is just in the skeleton...

Code Select Expand

.if al>="7"
jmp yea
.endif

.if al==("V") ;not wanted
xor eax, eax
ret
.endif

.if al==VK_RETURN
jmp yea
.endif

,else
xor eax, eax
ret

yea:
invoke CallWindowProc,OldWndProc,hEdt,uMsg,wParam,lParam
ret

The above samples are not meant to compile, just for illustration.

[Tedd]

OK, got that, makes sense, but just to be crystal clear: by "no other processing", what do you mean exactly?
I take that to mean "no calls into the Windows API". Is that correct? (Meaning, for instance, that it would be OK to look at, say, wParam and lParam values; that wouldn't fall under the heading of "processing" in this case.)

DefWindoProc provides basic default handling for any messages that require it, and does nothing much with messages that don't (other than return an appropriate 'confirmation' value.) So, you do what you want in response to the messages you're interested in, and if not then you throw it to DefWindowProc to deal with instead.
Yes, of course you need to examine the message first to check whether or not you're interested - I wouldn't consider that processing to deal with the message (just checking to see if you want to deal with it.) If you must call API functions to make that decision, that's also fine - and you could still end up throwing it on to DefWindowProc anyway.

[Tedd]

Dave and Petezl, adding extra layers of complexity to the explanation isn't helping.
Of course there are numerous what-ifs and exceptions to everything, but throwing these at someone seeking to understand the basics only confuses the matter.

[Tedd]

When processing a message, return what the particular message (e.g., WM_PAINT) says to return. This seems to be generally zero. (At least on successful completion; there are always possible error conditions ...)

Yes.

For unprocessed messages, call DefWindowProc(). Don't set EAX on return from the window proc; just pass on the return value from DefWindowProc().

Yes.

DefWindowProc() can also be called before doing processing (as suggested by jj). I'm not sure exactly what cases one would want to do this in, though. More explanation, jj? (And someone else here contradicted this, saying you shouldn't call DefWindowProc() and do processing. So there seems to be some disagreement about this ...)

You can if it happens to do some useful processing as a result. In the majority of cases, you won't want to do this.

"Processing a message" is defined as calling into the Windows API in one's window proc.

So do you agree with this?

Not exactly. Processing a message simply means dealing with it appropriately - whatever you happen to do in the course of that (calling other functions or not) doesn't matter too much, only that you've sufficiently dealt with the message. And that is all DefWindowProc does (deal sufficiently with the messages you pass on to it.)

[dedndave]

Dave and Petezl, adding extra layers of complexity to the explanation isn't helping.
Of course there are numerous what-ifs and exceptions to everything, but throwing these at someone seeking to understand the basics only confuses the matter.

wow - that's pretty harsh, Tedd - lol
just because my answer does not match your answer is no reason to poop on it

but, we'll let you handle this one from now on

[NoCforMe]

"Processing a message" is defined as calling into the Windows API in one's window proc.

So do you agree with this?

Not exactly. Processing a message simply means dealing with it appropriately - whatever you happen to do in the course of that (calling other functions or not) doesn't matter too much, only that you've sufficiently dealt with the message. And that is all DefWindowProc does (deal sufficiently with the messages you pass on to it.)

Got it. I have a pretty good "handle" on this now (bad pun intended). Thanks.

[Tedd]

wow - that's pretty harsh, Tedd - lol
just because my answer does not match your answer is no reason to poop on it

No need to take offence. It's not about matching my answer, all I meant was that going into exceptional details of rare cases and exceptions to the normal processing are not helping answer what should be a straightforward question. Doing so only leads to further confusion and questions irrelevent to the original subject. Those details are interesting as a seprate issue, but it's not entirely helpful to push beginners in at the deep end.

[jj2007]

DefWindowProc() can also be called before doing processing (as suggested by jj). I'm not sure exactly what cases one would want to do this in, though. More explanation, jj? (And someone else here contradicted this, saying you shouldn't call DefWindowProc() and do processing. So there seems to be some disagreement about this ...)

You can if it happens to do some useful processing as a result. In the majority of cases, you won't want to do this.

I can echo that. Most of the time WM_PAINT does surprisingly little useful things, since the control's background is handled by WM_ERASEBKGND, and the borders by WM_NCPAINT. But there are exceptions, for example Iczelion's syntax highlighting tut 35:

   1. subclass the richedit control and handle WM_PAINT message within your own window procedure
   2. When it receives WM_PAINT message, it calls the original window procedure of the richedit control to let it update the screen as usual.
   3. After that, we overwrite the words to be hilighted with different color