After the Thread execute the program does not exit as it should ?

[Dogim]

Usual sequence is PostQuitMessage (or sending of WM_QUIT), and after that - DestroyWindow.

You can make reaction for WM_FINISH like this:

Code Select Expand


invoke SendMessage,[hWnd],WM_CLOSE,0,0
ret


Or something like - sorry, I'm not very familar with GoAsm yet.

This Will shutdown the whole program as soon as the secondary Thread stops executing, so if you want to restart the secondary thread again, your gonna have to start the whole program again.

Well, I'm not dig into the program itself. I just suggest a sequence of things to close window, you can adapt anything for your needs  :U

Thanks for all the tips, it does work however, so ill use all in my further programming journey  :U

[donkey]

Hi Dogim,

Some unsolicited advice:

NEVER use SendMessage or PostMessage to send a WM_QUIT message, the only reliable way to use that message is PostQuitMessage. When sending the WM_CLOSE message to your own application be sure to use PostMessage, SendMessage will wait for it to return and though it does not currently present a problem it may on future versions of Windows if the window destructor sequence is changed. I usually use WM_CLOSE as it allows my program to process all unfinished business and free resources within a single message handler, PostQuitMessage can be executed from the WM_CLOSE handler so that the Close button and the Exit menu item will execute the same wrap up code. Also I found out early that using PostQuitMessage all over the program can complicate debugging on larger programs, a single call in the WM_CLOSE handler is much easier to deal with.

Edgar

[Antariy]

Hi Dogim,

Some unsolicited advice:

NEVER use SendMessage or PostMessage to send a WM_QUIT message, the only reliable way to use that message is PostQuitMessage. When sending the WM_CLOSE message to your own application be sure to use PostMessage, SendMessage will wait for it to return and though it does not currently present a problem it may on future versions of Windows if the window destructor sequence is changed. I usually use WM_CLOSE as it allows my program to process all unfinished business and free resources within a single message handler, PostQuitMessage can be executed from the WM_CLOSE handler so that the Close button and the Exit menu item will execute the same wrap up code. Also I found out early that using PostQuitMessage all over the program can complicate debugging on larger programs, a single call in the WM_CLOSE handler is much easier to deal with.

Edgar

Yes, right, using of SendMessage is not proper. I'm too tired. But with using of PostMessage,WM_QUIT... I never had a problems, really.

[donkey]

Yes, right, using of SendMessage is not proper. I'm too tired. But with using of PostMessage,WM_QUIT... I never had a problems, really.

Perhaps you got lucky, I am looking for an old Win98SE program I had that BSODed when it was sent without PostQuitMessage, something in the window procedure that the program was doing caused a lock-up.

Remarks

The WM_QUIT message is not associated with a window and therefore will never be received through a window's window procedure. It is retrieved only by the GetMessage or PeekMessage functions.

Do not post the WM_QUIT message using the PostMessage function; use PostQuitMessage.

Edgar

[Dogim]

Yes, right, using of SendMessage is not proper. I'm too tired. But with using of PostMessage,WM_QUIT... I never had a problems, really.

Perhaps you got lucky, I am looking for an old Win98SE program I had that BSODed when it was sent without PostQuitMessage, something in the window procedure that the program was doing caused a lock-up.

Remarks

The WM_QUIT message is not associated with a window and therefore will never be received through a window's window procedure. It is retrieved only by the GetMessage or PeekMessage functions.

Do not post the WM_QUIT message using the PostMessage function; use PostQuitMessage.

Edgar

Thanks Donkey for the tip. :U