Windows API, Defined Terms, Numerical Equivalents

[raleeper]

I know that, for example, the following are defined equivalents:
  term                             numerical [hex]
WM_CREATE          001
WM_DESTROY           002
WM_SETFOCUS          007
WM_PAINT                  00F
WM_KEYDOWN         100
WM_CHAR                  102
WM_SYSKEYDOWN  104
WM_COMMAND       111
WM_MOUSEMOVE   200
WM_LBUTTONDOWN      201
WM_LBUTTONUP    202

Does there exist anywhere [easily accessible] a complete list of the numerical values of defined terms?

For now I'd be very happy wiht just the messages - WM_*

I'm considering using command tables rather than message loops in some windows procedures.  [I'd appreciate any comments on the viability of that approach, also]

Viva le forum! [owtte].  [OrWordsToThatEffect]

Thank you,
ral

[dedndave]

i can help you with WM_ strings

http://www.masm32.com/board/index.php?topic=16460.msg137899#msg137899

all the constants are, supposedly, defined in all the .H files windows.h, comctl32.h, and so on
Hutch has put most of them in windows.inc and winextra.inc   :P

[dedndave]

as for the idea of using a branch vector look-up table.....
i looked into it - it is hardly advantageous, really

however, i did come up with a method that has merit

let's say you have a list of messages you are going to handle......

Code Select Expand

;WM_CREATE                 ;1
;WM_DESTROY                ;2
;WM_MOVE                   ;3
;WM_SIZE                   ;5
;WM_SETFOCUS               ;7
;WM_PAINT                  ;0Fh
;WM_CLOSE                  ;10h
;WM_SETCURSOR              ;20h
;WM_GETMINMAXINFO          ;24h
;WM_COPYDATA               ;4Ah
;WM_DISPLAYCHANGE          ;7Eh
;WM_NCDESTROY              ;82h
;WM_NCHITTEST              ;84h
;WM_NCMOUSEMOVE            ;0A0h
;WM_KEYDOWN                ;100h
;WM_KEYUP                  ;101h
;WM_SYSKEYDOWN             ;104h
;WM_SYSKEYUP               ;105h
;WM_COMMAND                ;111h
;WM_HSCROLL                ;114h
;WM_VSCROLL                ;115h
;WM_ENTERIDLE              ;121h
;WM_CTLCOLORSCROLLBAR      ;137h
;WM_MOUSEWHEEL             ;20Ah
;WM_MOUSEHWHEEL            ;20Eh
;WM_ENTERMENULOOP          ;211h
;WM_EXITMENULOOP           ;212h

one thing you can do is to first eliminate all messages above your highest-handled

Code Select Expand

        mov     ecx,uMsg
        cmp     ecx,WM_EXITMENULOOP    ;212h
        ja      def_win_proc_exit
        jz      ExitMenuLoopCode    ;may as well - we already made the CMP

after that, repeatedly divide the list in 2 - kind of like a binary search
divide and conquer - we'll take  WM_NCMOUSEMOVE, next

Code Select Expand

        cmp     ecx,WM_NCMOUSEMOVE      ;0A0h
        jb      test_values_below_0A0h
        ja      test_values_above_0A0h
        jz      NcMouseMoveCode

keep dividing the list until each "section" is down to 2 to 4 messages - then use the standard method

the problem with vector tables is size and, they aren't really all that fast
i made one with a "standard" set of messages and it was slower than CMP/JZ
of course, a full-blown vector table would be fast
i used the 2 bits in CH to select a list, then scanned - each of the 4 lists had 2 to 7 messages in it
the method i have outlined above yields the best overall speed and size combination

[raleeper]

Sorry.  Either I'm even dumber than usual or this is [maybe almost] totally irrelevant to my question.

Thanks anyway.

i can help you with WM_ strings

http://www.masm32.com/board/index.php?topic=16460.msg137899#msg137899

...

[raleeper]

This, however, looks very useful.

But I am still looking for a complete list, and "branch vector look-up table"s - I thank you for the proper term (sincerely) - do not need to be so long if certain ranges can be identified as to-be-processed, cartain others as to-be-ignored, and so on.

Of course then we may need several tables + several items handled w/o tables.  Then we have to decide whether it is more efficient - and perhaps more importantly - more transparent [ie, understandable] to do it one way or the other.  The standard message loop ["case" for higher level languages]  is the ideal for transparency, and if I knew that C++ [eg] optimized case statements to use jump tables, etc,  when appropriate, that would incline me to use C++[eg].  But I dont think so.

I need a complete list of WM_s in order to make intelligent decisions in this regard.

Thanks, ral

as for the idea of using a branch vector look-up table.....
i looked into it - it is hardly advantageous, really

however, i did come up with a method that has merit

let's say you have a list of messages you are going to handle......

Code Select Expand

;WM_CREATE                 ;1
;WM_DESTROY                ;2
;WM_MOVE                   ;3
;WM_SIZE                   ;5
;WM_SETFOCUS               ;7
;WM_PAINT                  ;0Fh
;WM_CLOSE                  ;10h
;WM_SETCURSOR              ;20h
;WM_GETMINMAXINFO          ;24h
;WM_COPYDATA               ;4Ah
;WM_DISPLAYCHANGE          ;7Eh
;WM_NCDESTROY              ;82h
;WM_NCHITTEST              ;84h
;WM_NCMOUSEMOVE            ;0A0h
;WM_KEYDOWN                ;100h
;WM_KEYUP                  ;101h
;WM_SYSKEYDOWN             ;104h
;WM_SYSKEYUP               ;105h
;WM_COMMAND                ;111h
;WM_HSCROLL                ;114h
;WM_VSCROLL                ;115h
;WM_ENTERIDLE              ;121h
;WM_CTLCOLORSCROLLBAR      ;137h
;WM_MOUSEWHEEL             ;20Ah
;WM_MOUSEHWHEEL            ;20Eh
;WM_ENTERMENULOOP          ;211h
;WM_EXITMENULOOP           ;212h

one thing you can do is to first eliminate all messages above your highest-handled

Code Select Expand

        mov     ecx,uMsg
        cmp     ecx,WM_EXITMENULOOP    ;212h
        ja      def_win_proc_exit
        jz      ExitMenuLoopCode    ;may as well - we already made the CMP

after that, repeatedly divide the list in 2 - kind of like a binary search
divide and conquer - we'll take  WM_NCMOUSEMOVE, next

Code Select Expand

        cmp     ecx,WM_NCMOUSEMOVE      ;0A0h
        jb      test_values_below_0A0h
        ja      test_values_above_0A0h
        jz      NcMouseMoveCode

keep dividing the list until each "section" is down to 2 to 4 messages - then use the standard method

the problem with vector tables is size and, they aren't really all that fast
i made one with a "standard" set of messages and it was slower than CMP/JZ
the method i have outlined above yields the best overall speed and size combination

[dedndave]

this brings up another interesting point
by playing around, and watching which unhandled messages are received, i have
found a few that deserve a special branch, even though they go to DefWinwowProc
this will probably draw a lot of critisizism - but, i am getting used to that   :bg
i turn off the default prologue and epilogue, then....

Code Select Expand

        mov     ecx,[esp+8]                                  ;uMsg
        cmp     ecx,WM_SETCURSOR                             ;20h
        JZ      DefWindowProc

        cmp     ecx,WM_NCHITTEST                             ;84h
        JZ      DefWindowProc

        cmp     ecx,WM_CTLCOLORSCROLLBAR                     ;137h
        JZ      DefWindowProc

        cmp     ecx,WM_NCMOUSEMOVE                           ;0A0h
        JZ      DefWindowProc

        cmp     ecx,WM_ENTERIDLE                             ;121h
        JZ      DefWindowProc

        cmp     ecx,WM_THEMECHANGED                          ;31Ah - highest handled message
        JA      DefWindowProc

        push    ebp
        mov     ebp,esp
        jz      ThemeChangedCode
;
;
;
a typical window receives literally thousands of these messages   :P

[dedndave]

as you can see, the list above splits things up rather nicely
so, we can combine the two ideas mentioned above
this time, we may use the default prologue and epilogue.....

Code Select Expand

        mov     ecx,uMsg
        cmp     ecx,WM_SETCURSOR                             ;20h
        jb      test_1_to_1Fh_messages
        jz      DefWinProc_exit

        cmp     ecx,WM_NCHITTEST                             ;84h
        jb      test_21h_to_83h_messages
        jz      DefWinProc_exit

        cmp     ecx,WM_NCMOUSEMOVE                           ;0A0h
        jb      test_85h_to_9Fh_messages
        jz      DefWinProc_exit

        cmp     ecx,WM_ENTERIDLE                             ;121h
        jb      test_A1h_to_120h_messages
        jz      DefWinProc_exit

        cmp     ecx,WM_CTLCOLORSCROLLBAR                     ;137h
        jb      test_122h_to_136h_messages
        jz      DefWinProc_exit

        cmp     ecx,WM_THEMECHANGED                          ;31Ah - highest handled message
        jb      test_138h_to_319h_messages
        jz      ThemeChangedCode

DefWinProc_exit:
        pop     ebp
        JMP     DefWindowProc
;
;
;
now, the list is already split into 6 sections   :bg
use the divide-and-conquer method in those 6 branches

[raleeper]

dedndave:

I really appreciate your help.

I dont understand your last 2 posts at all - yet.

Manana.

Thakns, ral

[hutch--]

raleeper,

In the past I have done jump table message processing and while it did turn out slightly smaller in assembled size, you just cannot see the difference for having bothered. Most Windows messages fit into the 0 to 1024 range so its no big deal to make a table filled with a default location value then overwrite numbers in the table with the address of a message handler for that message but Windows messaging is so slow it just does not matter.

You can use the technique profitably where you have a massive range of options that are not predictable where you need very fast branching but message handling is not one of them.

[baltoro]

RALEEPER,   
Dave is an advanced being, you have to forgive him,...(he has presented you an algorithm for searching message queues and handling them at the speed of light)
Here's a copy of WinUser.h from the Platform SDK: Winuser.h (scroll down to line 1183 for standard Windows messages)
All the numerical values for the standard Windows messages are defined in the header files that your compiler inserts into your program.   
For example, for the C++ language, all the defines are located in WinUser.h. The Visual Studio IDE will open the file if you select it (highlight), and, right click, select from pop-up menu.   
For MASM, all the defines are called equates (equ), and are in the windows.inc file, as mentioned above. In the MASM text editor, you must manually locate the include files with the Open File Dialog Box.
The numerical values are the same between assembly language and the Windows Platform SDK files, of course.
Don't edit those header files (or, the Include files). I did that once, and, it took me weeks to figure out what I had done wrong (Don't Laugh !).
Here is a partial list of Windows Messages: Window Notifications, MSDN

[raleeper]

Thanks to baltoro, hutch, and all.

This is excellent, though I should have been able to find it myself.

I did not think of looking in Winuser.h.

You have convinced me that jump tables are not useful for message handling.