Doesn't this accomplish the same thing?
.ELSEIF uMsg==WM_COMMAND
mov eax,wParam
.IF eax==BUTTON_ID
wellll
let's see what other notifications might be sent from a button via WM_COMMAND
BN_DBLCLK
BN_DISABLE
BN_DOUBLECLICKED
BN_HILITE
BN_KILLFOCUS
BN_PAINT
BN_PUSHED
BN_SETFOCUS
BN_UNHILITE
BN_UNPUSHED
in all cases, the low word of wParam is the control identifier
and the high word is the notification code
most of us use MOVZX to get the word portions of wParam
it makes for nice efficient code
mov eax,uMsg
.if eax==WM_COMMAND
movzx edx,word ptr wParam+2 ;EDX = wParam high word (notification code)
.if edx==BN_CLICKED
movzx eax,word ptr wParam ;EAX = wParam low word (control identifier)
.if eax==CID_MYBUTTON
;
;
;
.endif
.endif
xor eax,eax ;return 0
.else
INVOKE DefWindowProc,hWnd,uMsg,wParam,lParam
.endif
ret
now, as it turns out, BN_CLICKED is equal to 0 :P
all the other BN_notification values are non-zero
so - if you compare the entire dword against the control ID, that happens to work
although - it isn't very clear that it's being checked - lol
if you later want to modify your code and test for one of the other notifications,
you may pull your hair out trying to figure out what's going on
xor eax,eax ;return 0
.else
INVOKE DefWindowProc,hWnd,uMsg,wParam,lParam
Not sure if that is a good strategy. The OS might still have other tasks to solve after the click. Usually it's safer to just let the DefWindowProc do its job. Unless you have ten million clicks per second, of course - then speed might be a consideration ;-)
when you receive a WM_COMMAND message, you should return 0 if you process it
i don't know how else to interpret that
other than - the OS has done it's thing
it is a notification of a button being clicked - i would think that's straightforward
:biggrin:
.if uMsg == WM_COMMAND
; ======== menu commands ========
.if wParam == 1000
invoke SendMessage,hWin,WM_SYSCOMMAND,SC_CLOSE,NULL
.elseif wParam == 1001
Refresh_It:
invoke SendMessage,hList,LB_RESETCONTENT,0,0
invoke EnumWindows,ADDR EnmProc,0
; etc .....
.endif
If you have no need to mess around with the old 16 bit leftovers, this has been reliable for many years.
Quote from: dedndave on October 23, 2012, 04:49:01 PM
when you receive a WM_COMMAND message, you should return 0 if you process it
i don't know how else to interpret that
other than - the OS has done it's thing
it is a notification of a button being clicked - i would think that's straightforward
Dave, you are probably right. I just checked the behaviour, and after the click you can see exactly the same sequence of messages, whether you return 0 or pass through DefWindowProc.