When constructing a dialog derived from CXTPDialogBaseImpl the base class creates a CXTPCommandBars object. In its constructor a CXTPCustomizeDropSource object is created and in its constructor 3 icons are loaded. Our GDI resource leak tool is identifying these as resource leaks. I ran the tool because I noticed the GDI count going up in our process whenever we launch a dialog that uses this base class. Where is the DestroyIcon code supposed to go. Looks like it should be in destructor which is devoid of code.

CXTPCustomizeDropSource::CXTPCustomizeDropSource(CXTPCommandBars* pCommandBars)
{
    m_hcurDelete   = XTPResourceManager()->LoadCursor(XTP_IDC_COMMANDBARS_DRAGDELETE);
    m_hcurMove     = XTPResourceManager()->LoadCursor(XTP_IDC_COMMANDBARS_DRAGMOVE);
    m_hcurCopy     = XTPResourceManager()->LoadCursor(XTP_IDC_COMMANDBARS_DRAGCOPY);
    m_pSheet       = NULL;
    m_pCommandBars = pCommandBars;

    m_hwndCapture = 0;
    m_pControl    = 0;
    m_bMove          = FALSE;
    m_bCopyOnly   = FALSE;
    m_pTarget     = NULL;
}

CXTPCustomizeDropSource::~CXTPCustomizeDropSource()
{
}

This is in the current release.

Hello,

What GDI resource leak tool you used for identifying resource leaks?

Regards,

Artem Gontarenko

We have a tool we wrote that hooks various APIs and tracks resource allocations. It uses debugging APIs to capture call stacks on allocation. When it lists any outstanding allocations we can double click an entry it shows on a call stack and it opens the source file in Visual Studio. It lets us start tracking and stop tracking on demand. So, I started tracking, brought up a dialog derived from the CJ class, closed the dialog and stopped tracking. Then I listed all outstanding resources and saw the "icon" resources and followed the stack and code.

I fixed this in the destructor by checking for non-null members and calling DestroyIcon. Just set a breakpoint in the constructor and destructor and you can see the allocation and see in the destructor the members are non null.

uploads/3213/CJLeak.zip" rel="nofollow - uploads/3213/CJLeak.zip

Video of ISpy detecting GdiCursor leak in toolkit pro.

I've changed code by calling GetGuiResources before and after LoadIcon/DestroyCursor/DestroyIcon and GetGuiResources returns same value before and after DestroyCursor/DestroyIcon functions. So this functions not clean GDI resources after LoadIcon call.

So I thik this is not a bug.

Regards,

Artem Gontarenko

Artem,

You are correct. I failed to run our tool again while invoking our dialog multiple times after first seeing the GdiCursor entries. We do that second test to see if multiple entries build up. I just did so running three times and only one cursor entry showed up for each line instead of three. The handles that show up are constants so the system is not loading another cursor unless I destroy the previously loaded cursor.