Quote:Original post by kingnosis
It looks to me like your problem is scope. You create hWndButton inside of the WM_CREATE case, so as soon as the windows procedure exits, your handle to the button is destroyed.

I believe that windows (such as buttons) get detroyed automatically, without you having to call a release function.

I'd say try making your button global, or static inside the WndProc.

kingnosis

Hi kingnosis.

These are only handles. Handles are not objects, therefore they don't have a destructor which is called when you go out of scope. A handle is 'destroyed' when
1) you DestroyWindow() it
2) you DestroyWindow() one of its ancestor.

@d1sc0rd:

a)the first BM_SETIMAGE was already working - the NULL return was correct, since it returns the previous associated bitmap handle. Since you just created the button, tyhere was no associated bitmap, hence the NULL return. You don't have to call it twice - just discard the NULL check. If you want to verify that your bitmap had been set by your SendMessage() call then you can issue another SendMessage() with BM_GETIMAGE. This will return you the handle of the current button bitmap.

Quote:Original post by d1sc0rd
I tried checking the return from the BM_GETSTATE as well. It should be returning 0 I think, which would be different from null, right?

b) #define NULL 0
So I guess that 0 and NULL should be the same :)

c) take care about your WM_CREATE handling. The MSDN states:

Quote:WM_CREATE return code
If an application processes this message, it should return zero to continue creation of the window. If the application returns –1, the window is destroyed and the CreateWindowEx or CreateWindow function returns a NULL handle.

d) I see nothing wrong with your code. Are you sure you see the button and no bitmap on it? Are you sure IDB_RIGHT_ARROW is correct? Can you try with a system bitmap (hBmp = LoadBitmap(NULL, MAKEINTRESOURCE(OBM_CHECK)); or hBmp = LoadBitmap(NULL, OBM_CHECK);, I don't remember which one is teh win).

It'll work if you send BM_SETIMAGE outside your WM_CREATE handler (try putting it in a WM_SHOWWINDOW handler). Why exactly that is, I'm not sure.

BTW, minor comment: don't do #include ".\resource.h". This attempts to escape the r character. Do one of the following:
#include "resource.h"
#include "./resource.h"
#include ".\\resource.h"
Never use a single backslash in a path name.

[Edited by - Kippesoep on January 20, 2005 4:55:10 AM]

Quote:Original post by Kippesoep
It'll work if you send BM_SETIMAGE outside your WM_CREATE handler (try putting it in a WM_SHOWWINDOW handler). Why exactly that is, I'm not sure.

BTW, minor comment: don't do #include ".\resource.h". This attempts to escape the r character. Do one of the following:
#include "resource.h"
#include "./resource.h"
#include ".\\resource.h"
Never use a single slash in a path name.

Side note: you can include "a\b\c.h" - this is processed by the precompiler, not the compiler itself, and you don't need to double your '\'. But this will probably don't work on non-Windows systems. As a consequence, I agree with Kippesoep and I believe it is better to avoid '\' in included file path.

Quote:Original post by d1sc0rd
OK I have found the problem, but I don't understand why it is a problem.
If I do not select the bitmap into the DC in WM_PAINT, the bitmap now appears on the button. Why can the bitmap not be selected into both?

Maybe this has something to do with your WM_PAINT handling. The msdn says that it should return 0 if you processed the message or non zero if you didin't processed it. You may try to return 1 at the end of your WM_PAINT handler. I'm not sure this will do what you want to do - and maybe you'll have some other problems.

Regards,