Thread: Button click out of WM_COMMAND

Originally Posted by Sober

What I need to do is to use the same button to stop processing.....I need to use something like keydown but I have not been able to get to know what it should be..

I've used what's below before to use the same button to toggle different actions based on odd/even.

Code:

	case IDC_SCRIPT:
            {
            buttoncheck++;

            if(buttoncheck %2==0)
            {
            //Do something
            }

                if(buttoncheck %2==1)
                 {
                 //Do something else
                 }
            }
            break;

I'm certain there's more eloquent (or proper) methods of doing it, but it works. Although, I don't know what precisely it is that you're doing, so maybe it won't be of use to you.

*Btw, I would've stuck to your earlier topic if I had seen it first. The Mods get somewhat annoyed when you start duplicate threads.

if threading look at 'critical sections', they allow only one thread to access your processing flag at a time.

Normally I do this by modifing the message pump. Using PeekMessage() instead of GetMessage(). MFC may be able to use OnIdle().
WaitMessage() may be helpful.

GetMessage waits until your app has a msg and will not return until your app has a msg.
PeekMessage just looks and returns with or without a msg.
WaitMessage will suspend a thread until a msg arrives for it.

If there is no msg for the app and enough time has passed since last screen update then redraw screen.

Code:

if(PeekMessage(&msg,NULL,0,0,PM_REMOVE)>0)
{
       //check for WM_QUIT
       //Translate and Dispatch
}
else update the screen ect

So thats what you mean I think:

Code:

   while( TRUE )
    {
        MSG msg;

        if( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
        {
            // Check for a quit message
            if( msg.message == WM_QUIT )
                break;

            TranslateMessage( &msg );
            DispatchMessage( &msg );
        }
        else
        {
            UpdateWindow(hwnd);
        }
    }

I have tried it thinking it may solve yet another problem of mine...
Actually in my applacaiton, I paint a BMP from a void function...
and some others in the WM_PAINT case from the switch (Message)...

When minimized and restored, only those BMP painted in the WM_PAINT are visible
but not those from the void function....

So I thought this message loop above would solve the problem
but I guess am wrong at understanding something here....
I mean which is related to the window's instance and the way the window is created...
Can anyone bring me light?

Originally Posted by Sober

Code:

         else
        {
            UpdateWindow(hwnd); I meant call your drawing method (which should redraw the screen and then call for a paint with InvalidateRect() / UpdateWindow()
        }
    }

When minimized and restored, only those BMP painted in the WM_PAINT are visible
but not those from the void function....

You are drawing to the screen DC. any changes are not remembered.

I have a screen buffer DC created with CreateCompatibleDC() / CreateCompatibleBitmap() ect.

I draw everything this buffer DC.
I then call for a paint (InvalidateRect() and UpdateWindow() )
In the WM_PAINT I BitBlt() from the buffer DC to the DC in the PAINTSTRUCT (or returned from BeginPaint() ), using the RECT in the PAINTSTRUCT.

Look for double buffering. Should be plenty of code posted here.....