Amasing how people who claim to be someone are the ones that really dont know much at all. This article was a nice attempt but dude did you not test this at all? Just a stupid question how would you use such code that is missing important parts of the process and does not generate a correct bitmap?
Heres whats missing since Roger didnt do his homework before jumping in for the test.
// point to DIB bits after BITMAPINFO object
WRONG ->//pDIBBits = (LPVOID*)(lpBI + 1);
int nColors = lpBI->bmiHeader.biClrUsed ? lpBI>bmiHeader.biClrUsed : 1 << lpBI->bmiHeader.biBitCount;
This is the proper way to handle the info in the header before processing the data bits, this works on 8 bit palette and 24 bit however at 256 colors or less you may want to create a Logical Palette to ensure the best color translation for the device your applying the bitmap to.
Oh and for the dude posting stupid sh*t about getting the size dude the clipboard format dictates what type of structure its working with and withen the structure of whatever type is header information stating what size the image or image data would be and if you cant simply look up the type of structure to find its size so you can extract the image info's params then maybe you shouldnt program. All Structures for windows are well commented and thats just stupid that you dont know this.
Your example is excellent, because the code is short simple and it works !
Hoewever there is an important issue that is not mentioned :
If you want to procces the graphics imported from the clipboard you need a local copy of the imported memory block. That would be easy if you know the size of the clipboard contents but apparently there is no general function for this ?
You might thinh that it is the users own problem to know the size of the imported structure because you have to decide on (or check for) the type of object you paste.
BUT, when you as in your code import a DIB you do not know the size, and apperently there is no function for that either in VC++6.0.
Note that when you read from file the problem does not exist because the total size of the DIB (or file) is written in the FILEINFOHEADER. But the information in the FILEINFOHEADER is not part of the DIB !
It must be fair to say that it is simply a desig-flaw that the total size in bytes, is not part of the DIB-structure !
But since it is so, what do you do to retrive the size of a DIB, since it is quite complicated to calculate it from all the other parameters present in the INFOHEADER ?
How I control the size of a window meta file when paste it?
example:
//write a WMF and put it into the clipboard.
void copy()
{
CMetaFileDC * m_pMetaDC = new CMetaFileDC();
CRect rc(0,0,20000,20000);
m_pMetaDC->CreateEnhanced(GetDC(),_T ("c:\\test.wmf"),&rc,"name");
//drawing the lines in the DC.....
HENHMETAFILE hMF= m_pMetaDC->CloseEnhanced();
//copy to the clipboard
OpenClipboard();
EmptyClipboard();
::SetClipboardData(CF_ENHMETAFILE,hMF);
CloseClipboard();
}
//then paste the file in a CRichEditView.
void CMyView::PasteIt()
{
GetRichEditCtrl()->Paste();
//clear the clipboard
OpenClipboard();
EmptyClipboard();
CloseClipboard();
}
In windows2000, I can control the size of the metafile with the third parameter of the function CreateEnhanced.But in Win98, the parameter have no function. Why? How control the size in win98?