Well, it's the problem dealing with multi-row bitmaps for Image list. Here is what happens: - When image list has single row bitmaps (image + mask) everything fine. - When image list has multi row bitmaps, wine's ImageLitst tries to rearrange them into single row. And this is where it fails. It's not as easy as it seems. Right now I'm messing with one simple case: Image list has 6 images 21x21 4 bit color in 84x63 bitmap. Plus masks (1 bit B&W). You can't just copy this byte by byte. Somewhere you have to copy bit by bit. Or combine bits from previous image with bits from current image.
Sunday, March 23, 2003, 6:24:04 PM, you wrote:
Hi Vitaliy,
I'm also working on a corruption problem that occurs in Visio's toolbars. It seems that we don't draw transparent images properly sometimes. The case that appears to be screwing up is when the imagelist's default background colour is CLR_NONE, and an image is drawn with CLR_DEFAULT as the background. The image gets random junk drawn where hbmMask is nonzero.
I think you're right about DIBSections... we should create and use them. The programmer who originally implemented Imagelist probably didn't know about it...
Mike
Vitaliy Margolen wrote:
For past few days I was trying to figure out what is the problem with corrupt bitmaps. Here is my findings:
- _read_bitmap does is not work right. The for() loop where it's restructuring original bitmap from multi-row into single-row.
- Windows creates DIBSection to keep original bitmap so it could be saved as is. This is not used that often. However development tools do use it. For example: Delphi.
I have few questions before making any hacking:
- Why do we use single row bitpams versus multi-row like native?
- Why we not creating DIBSection?