471,072 Members | 1,390 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,072 software developers and data experts.

PostQuitMessage different to PostMessage(hWnd, WM_QUIT, ...?

Is PostQuitMessage(?) different to PostMessage(hWnd, WM_QUIT, ... ) ?
I've got a window in a DLL (the same one experiencing the issue below,
"return value of WM_QUIT") in which PostMessage(hWnd, WM_QUIT, ... ) works,
but PostQuitMessage doesn't.

I would assume this to be the case as PostQuitMessage can't possibly know
the hWnd I'm wanting it to operate on. So why does the docs advise you to use
that?
Nov 17 '05 #1
17 6691
>Is PostQuitMessage(?) different to PostMessage(hWnd, WM_QUIT, ... ) ?
I've got a window in a DLL (the same one experiencing the issue below,
"return value of WM_QUIT") in which PostMessage(hWnd, WM_QUIT, ... ) works,
but PostQuitMessage doesn't.


PostQuitMessage probably does some housekeeping and sets a signal so
that GetMessage and PeekMessage behave appropriately.

As to why your code works with what you say and doesn't with PQM I
can't say because you've not provided any relevant information.
Presumably there's something odd with your message loop code?

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
Nov 17 '05 #2
I think the primary reason to introduce PostQuitMessage was because there
was no PostThreadMessage in Win16. PostQuitMessage works even after the main
window is destroyed or is being destroyed.
It may also make sure that all pending messages in the queue are handled
before the loop breaks. PostMessage(WM_QUIT) may not give such guarantee.

"David Lowndes" <da****@example.invalid> wrote in message
news:ka********************************@4ax.com...
Is PostQuitMessage(?) different to PostMessage(hWnd, WM_QUIT, ... ) ?
I've got a window in a DLL (the same one experiencing the issue below,
"return value of WM_QUIT") in which PostMessage(hWnd, WM_QUIT, ... )
works,
but PostQuitMessage doesn't.


PostQuitMessage probably does some housekeeping and sets a signal so
that GetMessage and PeekMessage behave appropriately.

As to why your code works with what you say and doesn't with PQM I
can't say because you've not provided any relevant information.
Presumably there's something odd with your message loop code?

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

Nov 17 '05 #3
>I think the primary reason to introduce PostQuitMessage was because there
was no PostThreadMessage in Win16.
As there weren't any threads it'd have been difficult ;)
It may also make sure that all pending messages in the queue are handled
before the loop breaks. PostMessage(WM_QUIT) may not give such guarantee.


Yes that's certainly a possibility.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
Nov 17 '05 #4
I've posted the code in the next message up... it shouldn't need anything
else other than that to compile. Can you possibly do me a favour please and
test it and see if it works for you?
"David Lowndes" wrote:
I think the primary reason to introduce PostQuitMessage was because there
was no PostThreadMessage in Win16.


As there weren't any threads it'd have been difficult ;)
It may also make sure that all pending messages in the queue are handled
before the loop breaks. PostMessage(WM_QUIT) may not give such guarantee.


Yes that's certainly a possibility.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

Nov 17 '05 #5
>I've posted the code in the next message up...

It's down how I've got my newsreader sorting! Do yourself a favour and
stick to posting in a single thread.

Your close issue is undoubtedly due to the fact that your calling
program will have its own message loop. Your nested loop should use
some other mechanism to break out. PQM is the wrong thing in this
circumstance since you don't want your application to quit. You may as
well just set a flag to terminate the nested loop.

Dave
Nov 17 '05 #6
So... what would you say is the solution to a problem whereby I need to
develop a login box, which should fit the following criteria:
1) Generic, reusable from any application, hence in its own DLL
2) Doesn't require a parent HWND, but should be able to act as a modal child
window if one is passed
3) Written in unmanaged code without MFC or ATL - i.e. buildable with the
SDK tools

How would you go about it?
Anything, as long as it fits the above 3 criteria...

"David Lowndes" wrote:
I've posted the code in the next message up...


It's down how I've got my newsreader sorting! Do yourself a favour and
stick to posting in a single thread.

Your close issue is undoubtedly due to the fact that your calling
program will have its own message loop. Your nested loop should use
some other mechanism to break out. PQM is the wrong thing in this
circumstance since you don't want your application to quit. You may as
well just set a flag to terminate the nested loop.

Dave

Nov 17 '05 #7
>So... what would you say is the solution..

I'd probably do much the same as you have, but I'd exit the nested
message loop using a flag rather than by faking WM_QUIT.

Dave
Nov 17 '05 #8
Can you possibly have a go at getting the code below to run, and see if you
get the same effect of the window "jumping around" when you click on its
caption as I get? Please?
(I get what you are saying about PQM / WM_QUIT - and yes I will use a flag.
But I don't think that will solve the issue of the window jumping around...
HINSTANCE hInst = NULL;
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
if(ul_reason_for_call == DLL_PROCESS_ATTACH)
hInst = (HINSTANCE)hModule;
return TRUE;
}

const _TCHAR* windowtitle = _T("AutoLogin");

LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch(uMsg)
{
case WM_CLOSE:
{
PostMessage(hWnd, WM_QUIT, NULL, NULL);
return 0;
}
}
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}

BOOL GetAutoLogin(HWND hWndParent, _TCHAR* buffer, long maxlen)
{
BOOL wasdisabled = EnableWindow(hWndParent, FALSE);

WNDCLASSEX wcx;
memset(&wcx, 0, sizeof(WNDCLASSEX));
wcx.cbSize = sizeof(WNDCLASSEX);
wcx.hbrBackground = (HBRUSH)(COLOR_3DFACE + 1);
wcx.hCursor = (HCURSOR)LoadImage(NULL, IDC_ARROW, IMAGE_CURSOR,
CW_USEDEFAULT, CW_USEDEFAULT, LR_SHARED);
wcx.hIcon = (HICON)LoadImage(NULL, IDI_APPLICATION, IMAGE_ICON,
GetSystemMetrics(SM_CXICON), GetSystemMetrics(SM_CYICON),
LR_SHARED);
wcx.hIconSm = (HICON)LoadImage(NULL, IDI_APPLICATION, IMAGE_ICON,
GetSystemMetrics(SM_CXSMICON), GetSystemMetrics(SM_CYSMICON),
LR_SHARED);
wcx.hInstance = hInst;
wcx.lpfnWndProc = WndProc;
wcx.lpszClassName = windowtitle;
wcx.lpszMenuName = NULL;
wcx.style = CS_HREDRAW | CS_VREDRAW;

ATOM a = RegisterClassEx(&wcx);
HWND hWnd = CreateWindow(
(LPCTSTR)a,
windowtitle,
WS_CAPTION | WS_POPUPWINDOW | WS_CHILD,
CW_USEDEFAULT,
CW_USEDEFAULT,
400,250,
hWndParent,
NULL,
hInst,
NULL);
ShowWindow(hWnd, SW_SHOWNORMAL);
UpdateWindow(hWnd);
MSG msg;
while(GetMessage(&msg, hWnd, NULL, NULL))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
DestroyWindow(hWnd);
UnregisterClass((LPCTSTR)a, hInst);

if(!wasdisabled) EnableWindow(hWndParent, TRUE);
return msg.wParam != 0;
}


"David Lowndes" wrote:
So... what would you say is the solution..


I'd probably do much the same as you have, but I'd exit the nested
message loop using a flag rather than by faking WM_QUIT.

Dave

Nov 17 '05 #9
Would it be possible to use DialogBox and create modal dialog?

"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:45**********************************@microsof t.com...
So... what would you say is the solution to a problem whereby I need to
develop a login box, which should fit the following criteria:
1) Generic, reusable from any application, hence in its own DLL
2) Doesn't require a parent HWND, but should be able to act as a modal child window if one is passed
3) Written in unmanaged code without MFC or ATL - i.e. buildable with the
SDK tools

How would you go about it?
Anything, as long as it fits the above 3 criteria...

"David Lowndes" wrote:
I've posted the code in the next message up...


It's down how I've got my newsreader sorting! Do yourself a favour and
stick to posting in a single thread.

Your close issue is undoubtedly due to the fact that your calling
program will have its own message loop. Your nested loop should use
some other mechanism to break out. PQM is the wrong thing in this
circumstance since you don't want your application to quit. You may as
well just set a flag to terminate the nested loop.

Dave

Nov 17 '05 #10
>Can you possibly have a go at getting the code below to run, and see if you
get the same effect of the window "jumping around" when you click on its
caption as I get? Please?


Perhaps someone else can find time to try it, I can't promise I can do
it any time soon.

Dave
Nov 17 '05 #11
I had thought of this, but I don't know what I would do when there isn't a
parent hWnd.
"Yan K. Avlasov" wrote:
Would it be possible to use DialogBox and create modal dialog?

"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:45**********************************@microsof t.com...
So... what would you say is the solution to a problem whereby I need to
develop a login box, which should fit the following criteria:
1) Generic, reusable from any application, hence in its own DLL
2) Doesn't require a parent HWND, but should be able to act as a modal

child
window if one is passed
3) Written in unmanaged code without MFC or ATL - i.e. buildable with the
SDK tools

How would you go about it?
Anything, as long as it fits the above 3 criteria...

"David Lowndes" wrote:
>I've posted the code in the next message up...

It's down how I've got my newsreader sorting! Do yourself a favour and
stick to posting in a single thread.

Your close issue is undoubtedly due to the fact that your calling
program will have its own message loop. Your nested loop should use
some other mechanism to break out. PQM is the wrong thing in this
circumstance since you don't want your application to quit. You may as
well just set a flag to terminate the nested loop.

Dave


Nov 17 '05 #12
ok no problem.
"David Lowndes" wrote:
Can you possibly have a go at getting the code below to run, and see if you
get the same effect of the window "jumping around" when you click on its
caption as I get? Please?


Perhaps someone else can find time to try it, I can't promise I can do
it any time soon.

Dave

Nov 17 '05 #13
Yan that is actually a good idea. Thanks. It's not perfect (yet) - but I'm
making more progress with it than I was before with CreateWindow. It works
perfectly from within a parent hWnd which is telling me that CreateWindow
isn't supposed to be used from within another message loop.

Do you know whether it's viable to create a "dummy" window which isn't
shown, that can 'host' the dialog box while itself remaining invisible? Would
I be able to give the "dialog" (or perhaps really the host window, but looks
like it's the dialog) a space in the taskbar?

"Yan K. Avlasov" wrote:
Would it be possible to use DialogBox and create modal dialog?

"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:45**********************************@microsof t.com...
So... what would you say is the solution to a problem whereby I need to
develop a login box, which should fit the following criteria:
1) Generic, reusable from any application, hence in its own DLL
2) Doesn't require a parent HWND, but should be able to act as a modal

child
window if one is passed
3) Written in unmanaged code without MFC or ATL - i.e. buildable with the
SDK tools

How would you go about it?
Anything, as long as it fits the above 3 criteria...

"David Lowndes" wrote:
>I've posted the code in the next message up...

It's down how I've got my newsreader sorting! Do yourself a favour and
stick to posting in a single thread.

Your close issue is undoubtedly due to the fact that your calling
program will have its own message loop. Your nested loop should use
some other mechanism to break out. PQM is the wrong thing in this
circumstance since you don't want your application to quit. You may as
well just set a flag to terminate the nested loop.

Dave


Nov 17 '05 #14

"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:59**********************************@microsof t.com...
I had thought of this, but I don't know what I would do when there isn't a
parent hWnd.

Could you use the desktop as parent?

Drew
Nov 17 '05 #15
Even better idea - thanks, I'll try it - forgot the desktop is a window!

"Drew Myers" <dr***************@esrd.com> wrote in message
news:e1**************@TK2MSFTNGP09.phx.gbl...

"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:59**********************************@microsof t.com...
I had thought of this, but I don't know what I would do when there isn't a
parent hWnd.

Could you use the desktop as parent?

Drew

Nov 17 '05 #16
"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:5F**********************************@microsof t.com...
Yan that is actually a good idea. Thanks. It's not perfect (yet) - but I'm making more progress with it than I was before with CreateWindow. It works
perfectly from within a parent hWnd which is telling me that CreateWindow
isn't supposed to be used from within another message loop.

Do you know whether it's viable to create a "dummy" window which isn't
shown, that can 'host' the dialog box while itself remaining invisible? Would I be able to give the "dialog" (or perhaps really the host window, but looks like it's the dialog) a space in the taskbar?


I believe it is valid to pass NULL as parent HWND to the DialogBox function.
It will have a "button" in the task bar. Just make sure that your code
behaves correctly in case GetParent() returns NULL. In that case HWND to the
desktop GetDesktopWindow is often used.
Just a couple of points: don't call DefWindowProc from your dialog
procedure. Close the dialog with the EndDialog function.


Nov 17 '05 #17
The problem could be:
You're specifying hwnd argument in GetMessage(). I'm not sure if it will
fetch WM_QUIT posted by PostQuitMessage or check for it otherwise.
If you destroy the window in the message loop, GetMessage will never return
FALSE. It will return -1.

"Bonj" <Bo**@discussions.microsoft.com> wrote in message
news:A5**********************************@microsof t.com...
Can you possibly have a go at getting the code below to run, and see if
you
get the same effect of the window "jumping around" when you click on its
caption as I get? Please?
(I get what you are saying about PQM / WM_QUIT - and yes I will use a
flag.
But I don't think that will solve the issue of the window jumping
around...
HINSTANCE hInst = NULL;
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
if(ul_reason_for_call == DLL_PROCESS_ATTACH)
hInst = (HINSTANCE)hModule;
return TRUE;
}

const _TCHAR* windowtitle = _T("AutoLogin");

LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM
lParam)
{
switch(uMsg)
{
case WM_CLOSE:
{
PostMessage(hWnd, WM_QUIT, NULL, NULL);
return 0;
}
}
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}

BOOL GetAutoLogin(HWND hWndParent, _TCHAR* buffer, long maxlen)
{
BOOL wasdisabled = EnableWindow(hWndParent, FALSE);

WNDCLASSEX wcx;
memset(&wcx, 0, sizeof(WNDCLASSEX));
wcx.cbSize = sizeof(WNDCLASSEX);
wcx.hbrBackground = (HBRUSH)(COLOR_3DFACE + 1);
wcx.hCursor = (HCURSOR)LoadImage(NULL, IDC_ARROW, IMAGE_CURSOR,
CW_USEDEFAULT, CW_USEDEFAULT, LR_SHARED);
wcx.hIcon = (HICON)LoadImage(NULL, IDI_APPLICATION, IMAGE_ICON,
GetSystemMetrics(SM_CXICON), GetSystemMetrics(SM_CYICON),
LR_SHARED);
wcx.hIconSm = (HICON)LoadImage(NULL, IDI_APPLICATION, IMAGE_ICON,
GetSystemMetrics(SM_CXSMICON), GetSystemMetrics(SM_CYSMICON),
LR_SHARED);
wcx.hInstance = hInst;
wcx.lpfnWndProc = WndProc;
wcx.lpszClassName = windowtitle;
wcx.lpszMenuName = NULL;
wcx.style = CS_HREDRAW | CS_VREDRAW;

ATOM a = RegisterClassEx(&wcx);
HWND hWnd = CreateWindow(
(LPCTSTR)a,
windowtitle,
WS_CAPTION | WS_POPUPWINDOW | WS_CHILD,
CW_USEDEFAULT,
CW_USEDEFAULT,
400,250,
hWndParent,
NULL,
hInst,
NULL);
ShowWindow(hWnd, SW_SHOWNORMAL);
UpdateWindow(hWnd);
MSG msg;
while(GetMessage(&msg, hWnd, NULL, NULL))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
DestroyWindow(hWnd);
UnregisterClass((LPCTSTR)a, hInst);

if(!wasdisabled) EnableWindow(hWndParent, TRUE);
return msg.wParam != 0;
}


"David Lowndes" wrote:
>So... what would you say is the solution..


I'd probably do much the same as you have, but I'd exit the nested
message loop using a flag rather than by faking WM_QUIT.

Dave

Nov 17 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by Geoff Cox | last post: by
1 post views Thread by Avanish Pandey | last post: by
4 posts views Thread by troloo | last post: by
5 posts views Thread by Hendrik Schober | last post: by
2 posts views Thread by Bonj | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.