Lockup in TrackPopupMenu

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   I have traced a lockup in our app to two things going on in CodeJock. We hare in CXTPCommandBars::TrackPopupMenu. It is calling CXTPPopupBar::PumPMessage. We get stuck with the GetMessage call in that code constantly getting a TTM_DEL message. When it gets the message, the code calls ::DispatchMessage. So far so good.

Except, the code ends up in CXTPToolTipContextToolTip::DelTool and it does this when we lock up

        PostMessage(TTM_DELTOOL, 0, reinterpret_cast<LPARAM>(lpToolInfo));

The result is that the PumpMessage code just keeps dispatch TTM_DELTOOL only to have another message posted right back to the message queue.

So how did I get into this state? On the context menu we have a flyout. And, we have a string in our string table that has value 65555 (0xffff). That becomes -1. As we move over the context menu, CJ will call OnToolHitTest for that item. But, CJ doesn't care that the value is -1 because the control has a tooltip on it.

Here is code down in CXTPCommandBar::OnToolHitTest:

    CString strTip = pControl->GetTooltip();
    if (strTip.GetLength() == 0)
        return -1;

It gets past that test and CXTPToolTipContext::FillInToolInfo is called. Then the stack unwinds to CXTPToolTipContext::FilterToolTipMessageHelper TTM_ADDTOOL is NOT called because nHit is -1. But, m_lastInfo is set to tiHit. Then we move onto a menu entry that is not a submenu and with an ID that is not -1. The FilterToolTipMessageHelper drops into the code that sends the TTM_ADDTOOL and the TTM_DELTOOL messages and in DelTool "lpToolInfo->uID and m_nToolTipBeingShownUid are both -1 and that causes the code to post TTM_DELTOOL again.

I'm thinking ... DelTool should never post that message when the uId is -1 since it never posts TTM_ADDTOOL when it is -1.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 886	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Topic: Lockup in TrackPopupMenu Posted: 16 September 2021 at 4:03pm
	I have traced a lockup in our app to two things going on in CodeJock. We hare in CXTPCommandBars::TrackPopupMenu. It is calling CXTPPopupBar::PumPMessage. We get stuck with the GetMessage call in that code constantly getting a TTM_DEL message. When it gets the message, the code calls ::DispatchMessage. So far so good. Except, the code ends up in CXTPToolTipContextToolTip::DelTool and it does this when we lock up PostMessage(TTM_DELTOOL, 0, reinterpret_cast<LPARAM>(lpToolInfo)); The result is that the PumpMessage code just keeps dispatch TTM_DELTOOL only to have another message posted right back to the message queue. So how did I get into this state? On the context menu we have a flyout. And, we have a string in our string table that has value 65555 (0xffff). That becomes -1. As we move over the context menu, CJ will call OnToolHitTest for that item. But, CJ doesn't care that the value is -1 because the control has a tooltip on it. Here is code down in CXTPCommandBar::OnToolHitTest: CString strTip = pControl->GetTooltip(); if (strTip.GetLength() == 0) return -1; It gets past that test and CXTPToolTipContext::FillInToolInfo is called. Then the stack unwinds to CXTPToolTipContext::FilterToolTipMessageHelper TTM_ADDTOOL is NOT called because nHit is -1. But, m_lastInfo is set to tiHit. Then we move onto a menu entry that is not a submenu and with an ID that is not -1. The FilterToolTipMessageHelper drops into the code that sends the TTM_ADDTOOL and the TTM_DELTOOL messages and in DelTool "lpToolInfo->uID and m_nToolTipBeingShownUid are both -1 and that causes the code to post TTM_DELTOOL again. I'm thinking ... DelTool should never post that message when the uId is -1 since it never posts TTM_ADDTOOL when it is -1.