Forum

Hi,

I must be missing something in my wrapper class. Whenever I call my insertRow() method, which creates a row in the contained CExtGridWnd object and sets the cell data, I see that the GDI object count increases. So as I add more and more rows of data, the number of objects goes into the thousands. The application gets slower and slower as items are added.

I’m running 2.30 right now... is it possible that there’s some cleanup code that I’m missing? I’ve tried to identify problems with BoundsChecker, and I do get a couple of errors that pop up constantly. It looks like a GDI object is getting selected into more than one DC at a time, and the call to DeleteObject fails because the object is still selected into another DC at the time of the call. Perhaps this is related?

Thanks,
Dave

There is not enough information in your message to come to any conclusion about GDI handle leaks in the grid control. We tested all Prof-UIS samples for leaks before releasing 2.30. Could you send us your test project demonstrating GDI handle leaks? We may guess that the problem has something to do with grid cell types inserted into your grid rows.

This is a slightly modified version of how I add each cell to the grid. I normally have to lookup the data that goes into the cell by checking a map, but for clarity’s sake, I’ve just inserted a const string.

CExtGridCell* pHeaderCell = GridCellGetOuterAtTop( i, 0);
CString header;
pHeaderCell->TextGet( header);
CExtGridCellStringDMColor* pCell = STATIC_DOWNCAST( CExtGridCellStringDMColor, GridCellGet( i, row, 0, 0, RUNTIME_CLASS( CExtGridCellStringDMColor)));
string data = "ThisIsATest"; // this value is normally pulled from a map
pCell->TextSet( data.c_str());

CExtGridCellStringDMColor is defined as:

class CExtGridCellStringDMColor : public CExtGridCellStringDM
{
    COLORREF textColor;
    COLORREF bgColor;
public:
    DECLARE_DYNCREATE( CExtGridCellStringDMColor );
    IMPLEMENT_ExtGridCell_Clone( CExtGridCellStringDMColor, CExtGridCellStringDM );
    CExtGridCellStringDMColor( CExtGridDataProvider * pDP = NULL);
    virtual COLORREF OnQueryTextColor( const CExtGridWnd & wndGrid, CDC & dc, LONG nVisibleColNo, LONG nVisibleRowNo, LONG nColNo, LONG nRowNo, INT nColType, INT nRowType, DWORD dwAreaFlags, DWORD dwHelperPaintFlags) const;
    virtual bool OnPaintBackground( const CExtGridWnd & wndGrid, CDC & dc,    LONG nVisibleColNo, LONG nVisibleRowNo, LONG nColNo, LONG nRowNo, INT nColType, INT nRowType, const RECT & rcCellExtra, const RECT & rcCell, const RECT & rcVisibleRange, DWORD dwAreaFlags, DWORD dwHelperPaintFlags) const;
    void setTextColor( COLORREF color) { textColor = color; }
    void setBgColor( COLORREF color) { bgColor = color; }
};

I pulled this code from the SimpleGrids application in the _InitDemoTable_Orders method. I hope you can figure out what I did wrong!

Thanks,
Dave

Your code seems to be OK. Your class is mostly similar to the CDemoColoredCell class available in the SimpleGrids sample but it just keeps color properties inside. If you modify the CDemoGrid::_InitDemoTable_Colors() method in this sample by changing the number of inserted rows, then you should note that the number of GDI handles allocated in SimpleGrids remains the same (does not change). Could you send us your test or real project that demostrates the leak? Is true that this leak appears in the information displayed on the Processes page of the Windows NT Task Manager tool with/without instrumenting the code with the Bounds Checker tool?

I will try to put together sample code that exhibits this problem today, and will send it to you when it’s ready.

By the way, yes, you can see the GDI leak in the Task Manager with or without the code instrumented.

We appreciate your help in finding and fixing a possible bug either in Prof-UIS or in your application.

I apologize for not creating a test application before blaming the grid control for the GDI leak. I wrote a test application using my CExtGridWndWrapper class, and it didn’t leak. I then went back to the offending application and stepped into the calls, and eventually found the culprit.

It turns out that in order to calculate the ideal column width to fit my text, I need to get a DC. I called GetDC(), but didn’t follow it up with a call to ReleaseDC(), because of this line in MSDN:

Unless the device context belongs to a window class, the ReleaseDC member function must be called...

which I figured that I didn’t need to call, since my DC does belong to a window class. Anyhow, I just added the call, and now the GDI object leak is gone.

Thanks again for your prompt responses!

You can always ask for our help and assistance when you need it and we’ll do our best to help you.