GetObject & HBITMAP

[Nosferatu]

This is a continuation of the previous question (thanks LB).

When using GetObject to get the BITMAPINFO structure from a HBITMAP, it fills all the structure's fields, except the last one, the most important for me, bmBits.

When using the same handle to DRAW the bitmap, it works fine...

I would like primary access to the bitmap bits...

Does anybody has any idea about this?

Thank you. [red]Nosferatu[/red]
We are what we eat...
There's no such thing as free meal...
once stated: methane@personal.ro

 

[Nosferatu]

I found out what was wrong...

Actually, nothing was wrong, but GetObject fills only the "statistic" data when used for retrieving a BITMAP structure for a bitmap that was NOT created by CreateDibSection, that is bmWidth, Height, bitPlanes etc.

Anyway, for now I am stuck with GetBitmapBits function, which is provided only for backward compatibility with win16... I find this a bit anoying, because aparently there is no simple straight way to get the bitmap bits (only if you have a HDC...).

I would appreciate if anybody could point me to another way of getting the bitmap bits, outside any device context and without having to read the bits straight from the file (that is, using the HBITMAP).
Thanks. [red]Nosferatu[/red]
We are what we eat...
There's no such thing as free meal...
once stated: methane@personal.ro

 

[RbgoWeb]

bmBits should be a LPVOID to a byte array.
try...
BYTE* lpBits = (BYTE *)bmBits;
...and go from there.

I wonder why you try to avoid doing it this way.
The only other way I can think of doing this is to read a bitmap staight from a resource. But that is the same amounth of work plus a lot more.

 

[Nosferatu]

... well...

You probably know that when converting a NULL (!!!) pointer to anything else you will still get a... NULL (!!!) pointer!

So what I said above still holds and moreover, I think it is correct... [red]Nosferatu[/red]
We are what we eat...
There's no such thing as free meal...
once stated: methane@personal.ro

 

[RbgoWeb]

Do you mean that the LPVOID points to nothing instead of the pixel/color data of the bitmap?

 

[Nosferatu]

Yes that's right... And the reason for this is stated in my self-answer...
But the reason for that reason remains bleak to me. Why did MS had to do it this way, I don't know. Anyway, I am using GetBitmapBits function, even if its usage is descouraged. [red]Nosferatu[/red]
We are what we eat...
There's no such thing as free meal...
once stated: methane@personal.ro

 

[AmkG]

My copy of Win32.hlp informs me that I should use GetDIBits instead of GetBitmapBits...

int GetDIBits(
    HDC  hdc,	// handle of device context 
    HBITMAP  hbmp,	// handle of bitmap 
    UINT  uStartScan,	// first scan line to set in destination bitmap  
    UINT  cScanLines,	// number of scan lines to copy 
    LPVOID  lpvBits,	// address of array for bitmap bits 
    LPBITMAPINFO  lpbi,	// address of structure to put bitmap data in
    UINT  uUsage 	// RGB or palette index 
   );

Parameters

hdc - Identifies the device context.

hbmp - Identifies the bitmap.

uStartScan - Specifies the first scan line to retrieve.

cScanLines - Specifies the number of scan lines to retrieve.

lpvBits - Points to a buffer to receive the bitmap data. If this parameter is NULL, the function passes the dimensions and format of the bitmap to the BITMAPINFO structure pointed to by the lpbi parameter.

lpbi - Points to a BITMAPINFO structure that specifies the desired format for the device-independent bitmap (DIB) data.


uUsage - Specifies the format of the bmiColors member of the BITMAPINFO structure. It must be one of the following values:

Value Meaning
DIB_PAL_COLORS The color table should consist of an array of 16-bit indices into the current logical palette.
DIB_RGB_COLORS The color table should consist of literal red, green, blue (RGB) values.


Return Value:
If the lpvBits parameter is non-NULL and the function succeeds, the return value is the number of scan lines copied from the bitmap.

Windows 95:
If the lpvBits parameter is NULL and GetDIBits successfully fills the BITMAPINFO structure, the return value is the total number of scan lines in the bitmap.

Windows NT:
If the lpvBits parameter is NULL and GetDIBits successfully fills the BITMAPINFO structure, the return value is non-zero.

If the function fails, the return value is zero.

Remarks
If the requested format for the DIB matches its internal format, the RGB values for the bitmap are copied. If the requested format doesn't match the internal format, a color table is synthesized. The following table describes the color table synthesized for each format.

Value Meaning
1_BPP The color table consists of a black and a white entry.
4_BPP The color table consists of a mix of colors identical to the standard VGA palette.
8_BPP The color table consists of a general mix of 256 colors defined by GDI. (Included in these 256 colors are the 20 colors found in the default logical palette.)
24_BPP No color table is returned.
If the lpvBits parameter is a valid pointer, the first six members of the BITMAPINFOHEADER structure must be initialized to specify the size and format of the DIB. Note that a bottom-up DIB is specified by setting the height to a positive number, while a top-down DIB is specified by setting the height to a negative number. The bitmap's color table will be appended to the BITMAPINFO structure.
If lpvBits is NULL, GetDIBits examines the first member of the first structure pointed to by lpbi. This member must specify the size, in bytes, of a BITMAPCOREHEADER or a BITMAPINFOHEADER structure. The function uses the specified size to determine how the remaining members should be initialized.

If lpvBits is NULL and the bit count member of BITMAPINFO is initialized to zero, GetDIBits fills in BITMAPINFOHEADER or BITMAPCOREHEADER without the color table. This technique can be used to query bitmap attributes.
The bitmap identified by the hbmp parameter must not be selected into a device context when the application calls this function.
The origin for a bottom-up DIB is the lower-left corner of the bitmap; the origin for a top-down DIB is the upper-left corner.

See Also

BITMAPCOREHEADER, BITMAPINFO, BITMAPINFOHEADER, SetDIBits
"Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[Nosferatu]

Yes, I knew that, but I just did not wanted to create a DC and select the bitmap into it, just to get the Bitmap bits, since they are there anyway... [red]Nosferatu[/red]
We are what we eat...
There's no such thing as free meal...
once stated: methane@personal.ro

 

[AmkG]

I think the reason why M$uck did that was to make life harder for all of us. So we have to create a compatible DC, select the bitmap into it, then get the bitmap bits, then delete the DC. Instead of the more straightforward way of just getting the bits directly.

Of course it might have something to do with 32-bit memory protection, the bitmaps are in a special area reserved for M$uck Windows. Which Windows doesn't want anyone to access readily, for good reason.

Maybe I'll try to take apart Paint and see what Paint does to load/save bitmaps. "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[harmmeijer]

This post has nothing to do with the subject of the thread, it is a question for
dracula

If you have time, could you check thread426-261308 to see if I am on the right track?

 

[olie]

Does anyone know what is the code you use to load a RIFF palette file into ur application? (e.g. palette.pal)