Toolkit Pro - [solved] Dead lock in code peeking for WM

Print Page | Close Window

[solved] Dead lock in code peeking for WM_PAINT

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
URL: http://forum.codejock.com/forum_posts.asp?TID=22611
Printed Date: 25 December 2024 at 11:13am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: [solved] Dead lock in code peeking for WM_PAINT

Posted By: rdhd
Subject: [solved] Dead lock in code peeking for WM_PAINT
Date Posted: 27 May 2015 at 4:27pm

We have encountered certain cases where we dead lock the app due to code that looks like this:

        MSG msg;
        while (::PeekMessage(&msg, NULL, WM_PAINT, WM_PAINT, PM_NOREMOVE))
        {
            if (!GetMessage(&msg, NULL, WM_PAINT, WM_PAINT))
                return;
            DispatchMessage(&msg);
        }

In earlier versions of CJ, CXTPPopupControl had such a construct but it since been removed. We have been changing any code we have that does the above to use PM_REMOVE and removing the GetMessage call altogether. Depending on the window, you may or may not be able to remove the loop itself - most of this code will capture the mouse and after the peek look it calls GetMessage and if it isn't a mouse message DispatchMessage is called anyways. But for some windows, trailers are left on the screen that don't get repainted until the user lets up on the mouse.

In any case, with 16.3 CJ I still see a few places where this loop exists so there is the potential for a lockup. CJ might want to examine, e.g., CXTPDockingPaneContext::InitLoop. If m_bUseAlphaContext is false (for one of two reasons I could find), that look exists. I see the loop in CXTPTabClientWnd as well as the docking context. ITs in the XTPFlowGraphControl but we don't use that.

We started hitting this because we added a facebook UI element in our app (using the web browser control) and when a facebook timeline loads in the web page, any code that enters that loop has a high probability of locking up as the user moves the window (resizes, moves splitter etc.). It appears something in another thread is causing the WM_PAINT message to go missing between the main threads call to PeekMessage and the call to GetMessage in that loop (I didn't figure out where the WM_PAINT went to so that is supposition on my part).

In any case, it appears that with the popup control, CJ made the change a long time ago and I assume they noticed this too. Seems to be "standard" stuff as I found code we have for toolbars that is 20 years old that does the same thing.

Replies:

Posted By: astoyan
Date Posted: 11 June 2015 at 11:59pm

Hello rdhd,

It's a known issue and we'll try to fix it for the upcoming version. I'll keep you updated.

Thank you.

Alexander

Posted By: astoyan
Date Posted: 12 June 2015 at 11:11pm

Good news, the problem has been fixed in all places where pending WM_PAINT messages are processed. The changes will be available in the upcoming update.

Regards,

Alexander