Re: Toolbar icons with non-transparent background

Udo,

> I rebuild my image and having strange effects in toolbars (see attached
> jpg).

Just to confirm, you're talking about the different background colour on
the icons as compared to the toolbar itself?

> I know I had this fixed in my previous working image somehow but I can't
> remember how. I searched the archive but didn't find anything (or at
> least didn't searched for the right thing ;-).
>
> I'm pretty sure the fix was mentioned in c.l.s.d ... I just can't find
> it anymore.

There was a thread you started in the beta newsgroup about icons being
displayed with black backgrounds - is that the one you were thinking of?
  I can't, from a quick scan, see a mention of a fix though.

> Any hints are highly appreciated.

What OS are you using?.  FWIW, I don't see the same problem on XP SP2

Just FYI, Adding the jpg to your original post as an attachment means
there are a few news servers, and I think the number is increasing, who
will delete it immediately as spam (NIN did).  It's best to either
inline it (a Dolphin byte array would do) or put it somewhere else and
link to it.

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Ian,

> Just to confirm, you're talking about the different background colour on
> the icons as compared to the toolbar itself?
Exactly.

> There was a thread you started in the beta newsgroup about icons being
> displayed with black backgrounds - is that the one you were thinking of?
>  I can't, from a quick scan, see a mention of a fix though.
This issue was fixed in the release. So I 'm pretty sure we are seeing
another effect here.

> What OS are you using?.  FWIW, I don't see the same problem on XP SP2
XP Prof. SP2 ..... with WXP Theme .... not classic.

But I'm seeing this effect in both "Themes" ... just the background
color changes.

> Just FYI, Adding the jpg to your original post as an attachment means
> there are a few news servers, and I think the number is increasing, who
> will delete it immediately as spam (NIN did).  It's best to either
> inline it (a Dolphin byte array would do) or put it somewhere else and
> link to it.
Thanks for the hint. I realized it this morning and sent another message
with an embedded URL.

CU,

Udo

All,

I "somehow" solved this problem by patching
ToolbarIconButton>>renderBitmap as follows (original code is in comments):

renderBitmap
        "bitmap := Bitmap displayCompatibleWithExtent: self toolbar bitmapSize."
        | image |
        bitmap := Bitmap
                                width: self toolbar bitmapSize x
                                height: self toolbar bitmapSize y
                                depth: 32.
        (bitmap canvas)
                backcolor: Color face3d;
                erase.
        image := self commandDescription image.
        image ifNil: [image := self class defaultImage].
        (image class imageManager imageListWithExtent: bitmap extent)
                draw: image imageIndex
                on: bitmap canvas
                at: Point zero.
        bitmapIndex := 0


This solves the issue here .... but I'm not sure this is the right way
to go.

CU,

Udo

Udo Schneider wrote:
> All,
>
> I "somehow" solved this problem by patching
> ToolbarIconButton>>renderBitmap as follows (original code is in comments):
>
An updated version which should work in all color depths:
renderBitmap
        "bitmap := Bitmap displayCompatibleWithExtent: self toolbar bitmapSize."
        | image |
        bitmap := Bitmap
                                width: self toolbar bitmapSize x
                                height: self toolbar bitmapSize y
                                depth: Canvas forDisplay colorDepth.
        (bitmap canvas)
                backcolor: Color face3d;
                erase.
        image := self commandDescription image.
        image ifNil: [image := self class defaultImage].
        (image class imageManager imageListWithExtent: bitmap extent)
                draw: image imageIndex
                on: bitmap canvas
                at: Point zero.
        bitmapIndex := 0


What's strange for me is the fact, that the only difference between the
two versions is the /compatible/ bitmap. The original version creates
the bitmap as being compatible to the Display where as my "patch"
creates a bitmap with "just" the same attributes.

CU,

Udo

Udo Schneider wrote:
> All,
>
> I "somehow" solved this problem by patching
> ToolbarIconButton>>renderBitmap as follows (original code is in comments):
>
An updated version which should work in all color depths:
renderBitmap
        "bitmap := Bitmap displayCompatibleWithExtent: self toolbar bitmapSize."
        | image |
        bitmap := Bitmap
                                width: self toolbar bitmapSize x
                                height: self toolbar bitmapSize y
                                depth: Canvas forDisplay colorDepth.
        (bitmap canvas)
                backcolor: Color face3d;
                erase.
        image := self commandDescription image.
        image ifNil: [image := self class defaultImage].
        (image class imageManager imageListWithExtent: bitmap extent)
                draw: image imageIndex
                on: bitmap canvas
                at: Point zero.
        bitmapIndex := 0


What's strange for me is the fact, that the only difference between the
two versions is the /compatible/ bitmap. The original version creates
the bitmap as being compatible to the Display where as my "patch"
creates a bitmap with "just" the same attributes.

CU,

Udo

Udo Schneider wrote:
> All,
>
> I "somehow" solved this problem by patching
> ToolbarIconButton>>renderBitmap as follows (original code is in comments):
>
An updated version which should work in all color depths:
renderBitmap
        "bitmap := Bitmap displayCompatibleWithExtent: self toolbar bitmapSize."
        | image |
        bitmap := Bitmap
                                width: self toolbar bitmapSize x
                                height: self toolbar bitmapSize y
                                depth: Canvas forDisplay colorDepth.
        (bitmap canvas)
                backcolor: Color face3d;
                erase.
        image := self commandDescription image.
        image ifNil: [image := self class defaultImage].
        (image class imageManager imageListWithExtent: bitmap extent)
                draw: image imageIndex
                on: bitmap canvas
                at: Point zero.
        bitmapIndex := 0


What's strange for me is the fact, that the only difference between the
two versions is the /compatible/ bitmap. The original version creates
the bitmap as being compatible to the Display where as my "patch"
creates a bitmap with "just" the same attributes.

CU,

Udo

All,

sorry for this "tripple-posting" ... Thunderbird seemed to have some
hickups :-)

CU,

Udo

Udo Schneider wrote:
> What's strange for me is the fact, that the only difference between the
> two versions is the /compatible/ bitmap. The original version creates
> the bitmap as being compatible to the Display where as my "patch"
> creates a bitmap with "just" the same attributes.

It was a faulty display driver. Once the driver was update everything
went smoothly. It seems that the Display Driver did not implement
FillRect() correctly ... i.e. the supplied color was not used .... it
was always white.

I've not seen this since the early W95 days ..... however I'm suprised
that obviously no other program did use FillRect on Bitmaps .... at
least not as far as I could see it.

CU,

Udo