I found the error seemed to surface with 1 bit bitmaps - I didn't know
the encoding used though and got stuck. I think it's copying bytes not
bits, which leads to corruption.
On Mon, 2003-03-24 at 02:57, Vitaliy Margolen wrote:
Well, it's the problem dealing with multi-row bitmaps for Image
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
For past few days I was trying to figure out what is the problem with corrupt
bitmaps. Here is my findings:
1. _read_bitmap does is not work right. The for() loop where it's restructuring
original bitmap from multi-row into single-row.
2. Windows creates DIBSection to keep original bitmap so it
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.
On March 23, 2003 08:57 pm, Vitaliy Margolen wrote:
1. _read_bitmap does is not work right. The for() loop where it's
restructuring original bitmap from multi-row into single-row.
Is there something fundamentally wrong with the approach, or
is just that the restructuring is broken. If it can be
Telling truth, I'm not sure. I can't think of any real reason why
some app would depend on this. There are number of functions to
alter image list.
Only one thing that might depend on this is some kind of development
environment. But this won't work without DIBSection any way.
The reason I was
