Codejock Developer Community : [solved] v17 BUG ProcessPendingPaintMessages hangs

[solved] v17 BUG ProcessPendingPaintMessages hangs : Hi Oleksandr,this seems to have...

Sat, 23 Apr 2016 05:28:05 +0000

Author: MacW
Subject: 22835
Posted: 23 April 2016 at 5:28am

Hi Oleksandr,

this seems to have been fixed successfully in 17.2. Thanks!

[solved] v17 BUG ProcessPendingPaintMessages hangs : Hello Fredrik,Highlighting of...

Sun, 24 Jan 2016 03:21:01 +0000

Author: olebed
Subject: 22835
Posted: 24 January 2016 at 3:21am

Hello Fredrik,

Highlighting of backstage commands for Office 2013 (except Word) or Visual Studio 2015 themes do not related with changes in CXTPDrawHelpers::ProcessPendingPaintMessages. I'm working on those themes now.

But changes in CXTPDrawHelpers::ProcessPendingPaintMessages have impact on DockinPane with next settings CXTPDockingPaneManager::SetAlphaDockingContext(FALSE) and CXTPDockingPaneManager::SetShowContentsWhileDragging(TRUE). We are looking for solution now.

Regards,
Lebed Oleksandr

[solved] v17 BUG ProcessPendingPaintMessages hangs : Hi, is this perhaps related to...

Sat, 23 Jan 2016 20:06:24 +0000

Author: Fredrik
Subject: 22835
Posted: 23 January 2016 at 8:06pm

Hi, is this perhaps related to what I have reported twice, last in the last message in the following post? http://forum.codejock.com/forum_posts.asp?TID=22599&KW=&FID=112&PR=3&PID=74264&title=version-170-sneak-peek#74264

I.e. a workaround is to call m_pPaneManager.UseSplitterTracker with FALSE for now.

I submitted a support ticket for over two weeks ago how to easily reproduce the problem in CodeJock samples. No reply as so far. I wonder what happened with the expected response time of 24-48 hours...

[solved] v17 BUG ProcessPendingPaintMessages hangs : Hi, OleksandrI tried your solution....

Wed, 20 Jan 2016 03:59:33 +0000

Author: MacW
Subject: 22835
Posted: 20 January 2016 at 3:59am

Hi, Oleksandr

I tried your solution. It prevents the freeze, but has side-effects.
Your solution allows messages to be processed between the two PeekMessage calls. In my application this causes the following behavior:

I left-click the panel border and start dragging the border left or right. The panel resizes (no freeze,. good!) but then the 'mode' changes and the border stops following the mouse movements - like I had release the left mouse button. But the button is still pressed.

I have to release and left-click again to continue with the resizing.

In my solution, the user can move the border left and right to resize the panel until he releases the mouse button. This is the desired and normal behavior.

I think that the same effect happens in your solution: The first PeekMessage determines that a message needs to be processed. But before the second PeekMessage is called (the replacement for the GetMessage), the message is consumed. PeekMessage returns FALSE and the loop ends. This affects your mouse tracking or something.

The idea in my solution was to process the message straight away, without giving something else the chance to remove it from the message queue. This prevents blocking and unwanted side-effects.

[solved] v17 BUG ProcessPendingPaintMessages hangs : Yes, logic the same, butIf I change...

Tue, 19 Jan 2016 13:58:12 +0000

Author: olebed
Subject: 22835
Posted: 19 January 2016 at 1:58pm

Yes, logic the same, but

If I change whole method's body then it will be harder in future to track changes in this method with SVN.

That is why I want change just one line and ask you to test, please

[solved] v17 BUG ProcessPendingPaintMessages hangs : I' quite sure it will work.Both...

Tue, 19 Jan 2016 13:33:59 +0000

Author: MacW
Subject: 22835
Posted: 19 January 2016 at 1:33pm

I' quite sure it will work.

Both solutions avoid the potentially blocking call to GetMessage and use a PeekMessage with PM_REMOVE instead. This also pumps the paint messages, but avoids the risk of blocking in the case that the message is consumed between the PeekMessage and the GetMessage call.

[solved] v17 BUG ProcessPendingPaintMessages hangs : MacW wrote:MSDN says:Note that...

Tue, 19 Jan 2016 11:29:33 +0000

Author: olebed
Subject: 22835
Posted: 19 January 2016 at 11:29am

MacW wrote:

MSDN says:

Note that PeekMessage always retrieves WM_QUIT messages, no matter which values you specify for wMsgFilterMin and wMsgFilterMax.

so I considered it safer to handle this case and return FALSE.

Ok, I missed this. But have you tried my proposal ? (I can't yet reproduce behavior of your application on our samples.)

[solved] v17 BUG ProcessPendingPaintMessages hangs : MSDN says:Note that PeekMessage...

Tue, 19 Jan 2016 11:22:11 +0000

Author: MacW
Subject: 22835
Posted: 19 January 2016 at 11:22am

MSDN says:

Note that PeekMessage always retrieves WM_QUIT messages, no matter which values you specify for wMsgFilterMin and wMsgFilterMax.

so I considered it safer to handle this case and return FALSE.

[solved] v17 BUG ProcessPendingPaintMessages hangs : Hello MacW,Try to change in our...

Tue, 19 Jan 2016 08:29:31 +0000

Author: olebed
Subject: 22835
Posted: 19 January 2016 at 8:29am

Hello MacW,

Try to change in our version of ProcessPendingPaintMessages method

if (0 < ::GetMessage(&msg, hWnd, msgPeeked.message, msgPeeked.message))

with

if (::PeekMessage(&msg, hWnd, msgPeeked.message, msgPeeked.message, PM_REMOVE))

I have tested these changes on our samples without hangs.

Also I think

if (msg.message == WM_QUIT)

never be TRUE because msg.message can be only one of { WM_PAINT , WM_ERASEBKGND , WM_SYNCPAINT , WM_NCPAINT }

Regards,
Oleksandr Lebed

[solved] v17 BUG ProcessPendingPaintMessages hangs : This is all taking way too long....

Tue, 19 Jan 2016 05:23:49 +0000

Author: MacW
Subject: 22835
Posted: 19 January 2016 at 5:23am

This is all taking way too long. My users are killing me.
Over a week, and no feedback on this. I'm sorry to say but I wonder why I pay the fees every year.

Although I really hate to change Codejock code, I saw no other chance to fix this. I changed your code, which reliably freezes, with this code:

BOOL CXTPDrawHelpers::ProcessPendingPaintMessages(HWND hWnd /*= NULL*/)
    {
        MSG msg;
        const UINT MESSAGES[] = { WM_PAINT , WM_ERASEBKGND , WM_SYNCPAINT , WM_NCPAINT };

        while (true) {
            bool processed = false;
            for (int k = 0; k < _countof(MESSAGES); k++) {
                while (::PeekMessage(&msg, hWnd, MESSAGES[k], MESSAGES[k], PM_REMOVE)) {
                    if (msg.message == WM_QUIT) {
                        return FALSE;
                    }
                    ::DispatchMessage(&msg);
                    ::ValidateRect(msg.hwnd, NULL);
                    processed = true;
                }
            }
            if (!processed) return TRUE;
        }
    }

which (apparently) does the same as your code, but does not freeze the application. It's just a work-around but it does the job. I hope you can fix this more elegantly.