The Ultimate Message Loop

[dedndave]

on second thought....

the documentation says
exit = 0
error = -1

while it may be true (now) that success is always positive,
that doesn't mean they may not change it in future OS versions

[dedndave]

Code Select Expand

mLoop1: INVOKE  GetMessage,esi,edi,edi,edi
        inc     eax
        jnz     mLoop2

        INVOKE  MessageBox,0,offset szText,offset szTitle,MB_OK
;IDOK = 1
;but, if they close the MB...
        mov     al,1              ;could just as well JMP SHORT to exit

mLoop2: dec     eax
        jnz     mLoop0

;------------------------------

;exit program

        INVOKE  ExitProcess,[esi].MSG.wParam

it could be offered as an exit or continue option
although, as Hutch said - if it's bad, fix it - lol
i guess our pointer and handle are always valid values

[Tedd]

You guys worry me sometimes.
The message-loop has at least 3 API calls (more if you're handling accelerators, dialogs, etc.), none of which are super-fast; the overhead from condition testing is comparatively tiny. No matter how slick you make your tests, you're still going to be calling those big old messaging functions.
An additional free register in the message-loop isn't a concern because it's not the place for additional processing.
Just write it correctly and then forget about it.



On the subject of local Vs global variables: globals are for things that will be accessed from multiple places, locals are only for the procedure they're in. So the MSG structure is local to the message-loop because that's the only place it should ever be used. "hInstance" tends to be global because it's used from multiple places.

[Zen]

I think we have some SERIOUS OVERKILL now on this issue,...
Ha, Ha, Ha,...you guys are hilarious !!!  :icon_eek:
...As I mentioned along time ago,...in a MASM Forum thread far, far away,...
This is what happens when you ask a bunch of geniuses a simple question,...

[hutch--]

Tedd is right of course but HAY, you would not want to miss out on a really serious optimisation. 

[dedndave]

it never hurts to be more efficient
you write enough efficient code - it becomes habit

[Zen]

...I'm the GODZILLA of code bloat,... 8)

[Tedd]

Increasing efficiency is fine, as long as it still works correctly. The problem is when it comes at the cost of functionality because "that's not important" or "that most likely probably maybe won't happen, hopefully."
Software is used for its functionality, so that should be the top priority; if you can also make it faster, that's great too.

[hutch--]

I work on a barbarian view that building in error handling only produces more errors. One of the great joys of MASM is when you get it wrong it explodes in your face and usually the OS says less than nice things about your software. It is in fact no big deal to test a window handle or WNDCLASSEX structure to see if you get a valid return value and by doing so you don't have to waste your time and code handling errors that will never happen.

Code Select Expand


    test eax, eax
    jnz msgloop


Is all you need for correctly written code so why add garbage that will never be used ?