[solved] v17 BUG ProcessPendingPaintMessages hangs

Sometimes, when I resize a XTP pane with the mouse, XTP stops responding and hangs in

ProcessPendingPaintMessages

in the GetMessage() call.

The method is called from

void CXTPDockingPaneSplitterWnd::OnLButtonDown(UINT /*nFlags*/, CPoint point)

You first query if a message is available via PeekMessage(...) and then enter GetMessage.

This will block if messages are processing between your call to PeekMessage and the GetMessage call. This can happen on a fast PC I guess or if the system is under stress.

I can reproduce this at will with certain "expensive" panels which cause a lot of work when processing WM_SIZE. At all times, XTP stops in ProcessPendingPaintMessages(). This did not happen with the version before the 17 - whatever was the last update of XTP 16.x before that.

The only work-aronud I have found so far is do press <Windows>+<D> two times and then click on my window. This pushes new messages into the message queue and XTP wakes up because the blocking GetMessageCall returns.

The pane which always allows to reproduce this contains a CHtmlView.

I cannot send you my application, sorry

Basically I host a CHTMLView inside the panel, and this HTMLView renders Maps using OpenLayers. We have an embedded WebBrowser control in a HTMLView and this may cause problems because of the multi.-threaded nature of the CWebBrowserCtrl and how it processes messages.

Maybe you can repro it by embedding a CHtmlView in a panel and then let it navigate to a complex web page, then resize the panel.

I can reproduce it in 9/10 cased. I just click on the panel border and start moving it, and XTP freezes in the GetMessage call. The only reason for this is that between your four calls to PeekMessage and the GetMessage call, the message queue was emptied.

I thought I had a work-around by de-coupling the code that I run when W_SIZE is received by setting a timer instead and processing the code 1 second later. But still XTP blocks sometimes. When I disable the resizing of the CHTMLView in response to WM_SIZE, XTP does not block.

I even tried to handle the xtpPaneActionSplitterResizing and xtpPaneActionSplitterResized events, disabling the HTML view WM_SIZE handing between these two events. The idea was to wait until XTP has finished sizing the panel and then update the size of the HTMLView. Still, customers report that it still freezes sometimes on their machines.

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.

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.

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.

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.

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