CVSListBox produces memory Leaks - by AngusX

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 646445 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 2/23/2011 8:22:36 AM
Access Restriction Public


I tried to use a new CVSListBox but I got a lot of memory leaks.
There seems to be more than one problem.

The first leak is in CMFCVisualManager. I managed it by adding a "CMFCVisualManager::DestroyInstance();" in the destructor of my App, but it's an error anyway.

The second is much bigger problem. I could track it down to the following reason:
- OnInitDialog subclasses the Feature Pack controls in a CMFCControlContainer. This creates a new CVSListbox object for the control, creates the buttons AND the tooltips for the buttons.
- After that, DoDataExchange in my App will be called. The DDX_Control uses MY CVSListBox object for the control. When called, it detects, that the object isn't initialized and calls "ReSubclassControl" from "CMFCControlContainer". Up to this point everything is OK. ReSubclassControl detects that the control is already subclassed and deletes the old object, thats OK, too. But the Problem is due to the fact, that the tooltips of the buttons were deleted in "CMFCButton::OnDestroy"! But this function won't be called because I destroy the object but not the window.
Sign in to post a comment.
Posted by AngusX on 2/28/2011 at 10:53 PM
Does "fixed in MFC for the next major release of Visual Studio" mean "fixed in VS 2012" (or whenever the next version is released)? Or is there possibly an earlier fix in the VS 2010 redistributable (I think in MFC100.dll) or / and in VS 2010 SP1?
Posted by Microsoft on 2/28/2011 at 5:28 PM

Thanks for the report. This issue has been fixed in MFC for the next major release of Visual Studio.

Pat Brenner
Visual C++ Libraries Development
Posted by AngusX on 2/24/2011 at 5:47 AM
I've got a very, very, very nasty workaround (for everyone who has the same problem).

At first place a "CMFCVisualManager::DestroyInstance();" in the destructor of your dialog or, better, of your App. Then you get rid of the allocated CMFCVisualManager which won't be destroyed otherwise.

At next, we must get rid of the awful tooltips from the CVSListBox buttons. The tooltips will be destroyed in "OnDestroy" of the button, but we will resubclass the control and only delete the already allocated CVSListBox object, not destroy the control itself. For this I used all bad things you can do in C++ (unsafe casting). Here are the steps:

- Declare a helper class for CVSListBox:

class DummyListBox : public CVSListBox
    void Putzen();

void DummyListBox::Putzen()
    POSITION pos;

    pos = m_lstButtons.GetHeadPosition();
    while (pos)

- Declare a helper class for CMFCButton:

class DummyButton : public CMFCButton
    void Putzen();

void DummyButton::Putzen()
    m_pToolTip = NULL;

- Declare a variable bStartUp in your dialog.
- Set the variable to true in the constructor.
- In "DoDataExchange" add "if (!bStartUp)" before the DDX_Control for your CVSListBox control.
- In "OnInitDialog" insert the following three lines AFTER "CDialog::OnInitDialog();":

bStartUp = false;

Hope this helps everybody with the same problem until MS has a solution (I think a new MFC100.dll).
Posted by Microsoft on 2/23/2011 at 10:27 PM
Thank you for submitting feedback on Visual Studio 2010 and .NET Framework. Your issue has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.
Posted by Microsoft on 2/23/2011 at 9:13 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(