Hi all,

Whilst browsing MSDN to refresh my memory on the GetMessage function, i found some code (and documentation!) which appeared to have been written by someone who may or may not have been influenced by various illegal substances. Whatever he/she was on, I want some. It must make coding a lot of fun!

To summarise;

Return value

Type: BOOL

If the function retrieves a message other than WM_QUIT, the return value is nonzero.

If the function retrieves the WM_QUIT message, the return value is zero.

If there is an error, the return value is -1. For example, the function fails if hWnd is an invalid window handle or lpMsg is an invalid pointer. To get extended error information, call GetLastError.

Because the return value can be nonzero, zero, or -1, avoid code like this:

while (GetMessage( lpMsg, hWnd, 0, 0)) ...

The possibility of a -1 return value in the case that hWnd is an invalid parameter (such as referring to a window that has already been destroyed) means that such code can lead to fatal application errors. Instead, use code like this:

BOOL bRet;

while( (bRet = GetMessage( &msg, hWnd, 0, 0 )) != 0)
{ 
    if (bRet == -1)
    {
        // handle the error and possibly exit
    }
    else
    {
        TranslateMessage(&msg); 
        DispatchMessage(&msg); 
    }
}

... say wha?!

My head hurts :(

Do not confuse the Windows BOOL with the primitive type bool. In Windows, BOOL is a typedef'd int. It is called BOOL because the integer it stores is to be used for logical operations and not arithmetic operations. The primitive bool type remains for regular true/false logic.

as stated in the comments on that page:

Do not confuse the Windows BOOL with the primitive type bool. In Windows, BOOL is a typedef'd int. It is called BOOL because the integer it stores is to be used for logical operations and not arithmetic operations. The primitive bool type remains for regular true/false logic.

A native bool is at least 8 bits wide, wasting 7 bits, does this mean that we should abuse it to hold other values than 0 or 1 too and place a sidenote in the C++ spec to say that this is expected behaviour? :)

</sarcasm>

as stated in the comments on that page:

Do not confuse the Windows BOOL with the primitive type bool. In Windows, BOOL is a typedef'd int. It is called BOOL because the integer it stores is to be used for logical operations and not arithmetic operations. The primitive bool type remains for regular true/false logic.

A native bool is at least 8 bits wide, wasting 7 bits, does this mean that we should abuse it to hold other values than 0 or 1 too and place a sidenote in the C++ spec to say that this is expected behaviour?

</sarcasm>

A native bool is at least 8 bits wide, wasting 7 bits, does this mean that we should abuse it to hold other values than 0 or 1 too and place a sidenote in the C++ spec to say that this is expected behaviour?

#include <iostream>

int main() {
bool b = -1;

std::cout << b << ", " << (b == -1) << std::endl;

int *c = (int *)&b;
*c = -1;

std::cout << b << ", " << (b == -1) << std::endl;
}

On a related note, BBC BASIC was even worse, because it only treated -1 as being TRUE, and 0 as being FALSE. Anything else wasn't either value at all.

This is because TRUE == -1 == 11111111 11111111 11111111 11111111b and FALSE == 0 == 00000000 00000000 00000000 0000000b.

Makes sense i guess, but ugh. That caused me all kinds of grief back in the 90s...

Like everything else (well, almost everything else) in the Windows API that's looks weird on first sight, there's actually a valid historical reason for this. http://blogs.msdn.com/b/oldnewthing/archive/2013/03/22/10404367.aspx

But you can calm down. The standard message loop is fine. All the parameters are hard-coded (and therefore valid by inspection), save for the &msg parameter, which is still valid by inspection. So that case is okay. It has to be, for compatibility.

The people who need to worry are people who pass a variable as the window handle filter (because that window handle may no longer be valid), or pass dynamically-allocated memory as the lpMsg (because the pointer may no longer be valid), or who pass a nontrivial message filter (because the filter parameters may be invalid).