PRB: Brush Permanent Handle Map Doesn't Work on Windows 95

    CBrush *pBrush1 = new CBrush (RGB(255,0,0));
   CBrush *pBrush2 = new CBrush (RGB(255,0,0));

   CBrush *pOld = pDC->SelectObject(pBrush1);
   // Do some stuff in here

   // Don't rely on the return value from SelectObject being pBrush1
   pDC->SelectObject(pOld);

   // Instead, maintain the pointer to the object yourself
   delete pBrush1;
				

MORE INFORMATION

On Windows NT or Windows 3.x, if a successful call is made to create a brush object, then a unique handle will be returned. This isn't necessarily true on Windows 95. Consider the following code:

   HANDLE hBrush = ::CreateSolidBrush(RGB(255,0,0));
   HANDLE hBrush2 = ::CreateSolidBrush(RGB(255,0,0));

   // In this case, hBrush and hBrush2 will have different values on
   // Windows NT or Windows 3.x, so the following assert will succeed

   ASSERT(hBrush!=hBrush2);
				

On Windows 95, the above assert will fail. Windows 95 is optimized to detect when an application is creating a duplicate brush handle so it doesn't need to create a brand new brush, just maintain internal information about the brush and return the same handle.

This presents a problem for MFC's permanent handle map mechanism. The handle map maintains an entry that maps each GDI handle to the unique Visual C++ object (derived from CGdiObject) that encapsulates that handle. This is a one-to-one mapping. If a new Visual C++ object is created that encapsulates the same handle as the previous object, then the previous object's entry in the permanent handle map will be replaced. This in itself is not a problem, but if you rely on the handle map to return the original Visual C++ object, then your code could run into serious problems. For example:

    CBrush *pBrush1 = new CBrush (RGB(255,0,0));
   CBrush *pBrush2 = new CBrush (RGB(255,0,0));

   CBrush *pOld = pDC->SelectObject(pBrush1);
   // Do some stuff in here
   delete pDC->SelectObject(pOld);
   ASSERT_VALID(pBrush2);
   // On Windows NT or Windows 3.x, the above call to "delete"
   // will delete pBrush1. On Windows 95, the above call to "delete"
   // will delete pBrush2 and the ASSERT_VALID will fail.