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.