On Jul 28, 8:20 am, pjohnsen <[EMAIL PROTECTED]> wrote:
> From what I can see, what happens is this: If there is already a
> message for appshell in the queue when calling PostQuitMessage,
> appshell will eat the WM_QUIT message. One possible workaround is to
> also set a global quit flag when doing the PostQuitMessage and then
> let your message loop break out if this is set. Something like:
>
> while (!gQuit) {
> WaitMessage();
> while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) {
> if (msg.message == WM_QUIT) {
> gQuit = true;
> break;
> }
> if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
> {
> TranslateMessage(&msg);
> DispatchMessage(&msg);
> }
> }
> }
>
> and:
>
> case WM_DESTROY:
> PostQuitMessage(0);
> gQuit = true;
> break;
>
> Hope this helps,
>
> -Pelle
>
> On Jul 23, 10:59 am, pjohnsen <[EMAIL PROTECTED]> wrote:
>
>
>
> > I am occasionally seeing similar behavior, i.e. that an embedding app
> > hangs during shutdown on win32, though I haven't quite figured out
> > what is going on yet. I will try to look more into this.
>
> > -Pelle- Hide quoted text -
>
> - Show quoted text -
You have to make sure all windows that get created have actually
closed before termination. It is possible to send window terminations
followed too quickly by a WM_QUIT. If this happens and those
window(s) have not completely closed then WM_QUIT severs all ties. If
this happens, then either the app will crash or hang. I corrected the
exact same behavior by waiting and checking to make sure all windows
that are created no longer exist after I request them to terminate.
Then once satisfied I send the final WM_QUIT message. Until I
followed this pattern I received either crash or hang behavior but no
more.
_______________________________________________
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
