How to get an file-loaded bitmap to fit a static image container using StretchBlt ?

[Igor Vartanov]

May I ask a couple of very basic questions?

Sure.

Q: When one uses a 'CreateCompatible.. DC or Bitmap function, I understand that the the device context struct of the object created will be 'compatible' with that of the HDC input parameter. But when loading a bitmap from a file, if one only has the handle (HBITMAP), what is the 'compatible' DC reference to use since the newly loaded bitmap handle has no DC initially associated with it. Since the newly loaded bitmap is to be set into the existing interface, it should presumably have a compatible DC associated with it, but that is just the DC of the interface image container, so why do I need a separate DC for it. Why not just get the interface image container DC and use that for both?

One DC can select only one bitmap object (same to any other types of GDI objects like pens, brushes, fonts, etc.), and object selection releases previously selected object. Bitmap copying can be done only between two DCs that selected destination and source bitmaps each. To be able to copy/stretch a loaded bitmap you have to create a DC compatible with the target DC to select the bitmap to the DC.

Q: What is the precise meaning of 'compatible' in the above context? This sounds as though the newly created DC is not necessarily 'identical' with the input DC, but rather only 'compatible'. I would like a clear explanation of what is meant here by 'compatible'.

Real device can have a fixed palette. Memory context must be just compatible with the one, but this never means it should be identical to it. When copying between DCs is performed, the bitmap bits get transformed to comply with the target device capabilities. E.g. this way non-palette 24-bit RGB bitmap can be copied to grey-scale palette printer DC. This process of copying from memory DC to printer DC is called printing.

Q: Getting the size of the newly loaded bitmap appears to be essential to using StretchBlt to fit the bitmap into the interface image container, the size of which is obviously known. As far as mixing MFC and GDI stuff, while it may not be pretty, I couldn't find any pure way to accomplish basic things like getting the size of the newly loaded bitmap. For example, the following code works:

	BITMAP bm;	
	::GetObject( hBmp, sizeof( bm ), &bm );	
	int bmWidth = bm.bmWidth;
	int bmHeight = bm.bmHeight;

but I could not find how to use the MFC CBitmap or CImage classes to do this. I spent alot of time hunting for code examples but none found worked for me. As a pragmatist, I feel whatever works is OK with me. But I agree with your comment in this regard. The reason is that the internet is full of code that is mostly GDI and much of which doesnt work.

Mike, I can understand your approach of hunting for code snippets. But sometimes it's much easier to browse through documentation first.

CBitmap::GetBitmap internally does exactly what you showed here. CImage::GetWidth and CImage::GetHeight names are self-explaining enough. Besides, even with C++ objects like MFC CBitmap and ATL CImage you can fall back to plain GDI any time you want. You just need for that to retrieve the original GDI object handle the mentioned class objects wrap:
CBitmap:: operator HBITMAP
CImage:: operator HBITMAP