Toolbar icons

Hi all,

I'm trying to create some icons for my toolbars using Microangelo  
Creation. But, if I saved them as .ico it seems that it always displays  
another icon (seems to be the icon from the previous button). But if I  
save it as bitmap, the icon appears corrrectly, albeit without  
transparency. Is there something that I'm doing wrongly? The same .ico  
displays fine in the class browser when I tested it by overriding the  
class side #icon method of a class.

Incidently does anyone have any problem setting the #fileLocator aspect of  
a toolbar bitmap in the view composer? I can't seem to get it to save  
whenever I want to change it from say ImageRelativeFileLocator to  
FolderRelativeFileLocator. It only works for me if I opened an inspect on  
the bitmap and change from within the inspect.

--
Regards
Hwee Boon
MotionObj

Yar Hwee Boon wrote:

> I'm trying to create some icons for my toolbars using Microangelo
> Creation. But, if I saved them as .ico it seems that it always displays
> another icon (seems to be the icon from the previous button).

How did you manage to get an Icon to work in a toolbar ?  I thought you had to
use a Bitmap, and when I tried it just now, attempting to set the #bitmap: to
an Icon caused a walkback (Icon DNU #setMap3dColors:).


> Incidently does anyone have any problem setting the #fileLocator aspect of
> a toolbar bitmap in the view composer? I can't seem to get it to save
> whenever I want to change it from say ImageRelativeFileLocator to
> FolderRelativeFileLocator. It only works for me if I opened an inspect on
> the bitmap and change from within the inspect.

That's odd, it works OK for me.

Just to check, are we talking about setting the image of a ToolbarButton
specifically ?

    -- chris

On Sat, 28 Aug 2004 11:37:25 +0100, Chris Uppal  
<[hidden email]> wrote:

> How did you manage to get an Icon to work in a toolbar ?  I thought you  
> had to
> use a Bitmap, and when I tried it just now, attempting to set the  
> #bitmap: to
> an Icon caused a walkback (Icon DNU #setMap3dColors:).

I got the same walkback. My apologies, embarrasing to say, after trying  
for sometime I had mistakeningly used a Bitmap with the icon file  
instead... :P But that aside, does that mean that toolbars only work with  
bitmaps and not icons? If that's the case, how about transparency?

Yes. I just tried again on a fresh image. Here's what I did:

1. Open the Toolbar.'Class browser tools' resource.
2. Expand the items collection to display the fileLocator aspect of the  
#newClass button.
3. In the workspace, enter FolderRelativeFileLocator basePath: 'c:\'.
4. Ctrl-S.

Observe that the aspect value indicates it's updated. But if you inspect  
the bitmap aspect or do a refresh, it goes back to  
ImageRelativeFileLocator. Is that what you did?

--
Regards
Hwee Boon
MotionObj

Yar Hwee Boon wrote:

> does that mean that toolbars only work with
> bitmaps and not icons?

That's my understanding, although it's not something I know much about.  Part
of it is that the toolbar implementation is designed to work with one big
bitmap that's shared between several buttons, or even several Toolbars (using
the Toolbar's #imageSize and the ToolbarButton's #bitmapIndex to locate the
actual pixels needed for each button).


> If that's the case, how about transparency?

I'm afraid I don't know.  Do you need transparancy for something special, or
just to make the button images' backgrounds merge with the toolbar's own
colouring ?  (If it's the later then it seems to be handled for you, though I'm
hazy on the details.)


> 1. Open the Toolbar.'Class browser tools' resource.
> 2. Expand the items collection to display the fileLocator aspect of the
> #newClass button.
> 3. In the workspace, enter FolderRelativeFileLocator basePath: 'c:\'.
> 4. Ctrl-S.
>
> Observe that the aspect value indicates it's updated. But if you inspect
> the bitmap aspect or do a refresh, it goes back to
> ImageRelativeFileLocator. Is that what you did?

No, I had been twiddling the settings of a toolbar for one of my own
applications (one that uses a bitmap from an external, rather than a Bitmap
fromId: 'xxx').

When I follow your steps I get the same result as you.  I haven't investigated
what's going on (I'm currently enjoying a few glasses of wine whilst watching
the cricket, so my analytical faculties are somewhat below par...) but I wanted
to warn you that there seems to be some sort of object sharing going on.  When
I tried changing the #fileLocator in an inspector, it worked fine (just as you
said) but it /also/ changed that toolbar's definition /outside/ the instance in
the VC!  In fact inspecting the toolbar (with the "visual object finder" of
another CHB showed that the change had affected its toolbar too.  I decided to
kill that image without saving it ;-)

But now I see that Gloucestershire have opened their reply, and are six for
nought after one over, so more later...

    -- chris

On Sat, 28 Aug 2004 15:13:44 +0100, Chris Uppal  
<[hidden email]> wrote:

>> If that's the case, how about transparency?
>
> I'm afraid I don't know.  Do you need transparancy for something  
> special, or
> just to make the button images' backgrounds merge with the toolbar's own
> colouring ?  (If it's the later then it seems to be handled for you,  
> though I'm
> hazy on the details.)

Just to merge. After some digging around and testing, seems a 16-color  
bitmap with the background set to RGB(192, 192, 192) does the trick.  
Thanks.

Eeewww. Didn't know it might cause some complication, thanks for the  
warning! Enjoy your game :)

--
Regards
Hwee Boon
MotionObj

Hi,
The limitation of using bitmaps in toolbars is a problem sometimes, but
can be solved converting from icon to bitmap. I have added this method to
Icon class.

asBitmap: backcolor extent: extent

        |bmp|
        bmp := Bitmap compatible: Canvas forDisplay extent: extent.
        self drawOn: bmp canvas at:  0 @ 0 extent: extent frame: 1 background:
(Brush color: backcolor) flags: 3 .
        ^bmp


may be is useful for you. (I also have the Bitmap2Icon if you want it)

Diego

On Sun, 29 Aug 2004 00:39:07 -0400, DiegoC <[hidden email]> wrote:

Thanks, it should be useful with 3rd party icons.

--
Regards
Hwee Boon
MotionObj

DiegoC wrote:

> may be is useful for you. (I also have the Bitmap2Icon if you want it)

I'd like to see that, please.

    -- chris

Yar Hwee Boon wrote:

> > [...]  I wanted
> > to warn you that there seems to be some sort of object sharing going
> > on.  When
> > I tried changing the #fileLocator in an inspector, it worked fine (just
> > as you
> > said) but it /also/ changed that toolbar's definition /outside/ the
> > instance in the VC!

> Eeewww. Didn't know it might cause some complication, thanks for the
> warning! Enjoy your game :)

Right, /now/ I understand (mostly0, and it explains odd behaviour that I've
been seeing for ages without stopping to work it out.

It turns out that Dolphin has the ability to share Bitmaps.  See
Bitmap>>asSharedCopy, and go from there.

E.g:

    (Bitmap fromId: 'EditBar.bmp') realize.

will load a second copy of the bitmap from the "dolphindr005.dll" when #realize
is sent; but:

    (Bitmap fromId: 'EditBar.bmp') asSharedCopy realize.

will find the existing shared version of that bitmap (which is held in a weak
collection in Bitmap), and so the #realize will be a no-op because that bitmap
is already loaded.

When a Bitmap is loaded from STB such as a ViewResource, it checks to see if it
is shared, and uses the shared version if it is (and if there already is a
shared version loaded).  See Bitmap>>stbFixupAt:

Bitmaps are not shared by default, /but/ when one is used as the #bitmap: of a
ToolbarButton, the button sends #asSharedCopy to the bitmap it was supplied.
Hence all toolbar images are shared.

So, when you load Toolbar.'Class browser tools' into the VC, the #bitmap's of
all the ToolbarButtons will end up pointing to the same Bitmap instance as is
used for any open CHBs (and similar).  I haven't bothered to work out why the
VCs own PAI doesn't really save changes to the shared Bitmap (though I guess
it's lucky that it doesn't ;-), but that does explain why modifying those
objects with a full inspector does make rather more sweeping changes to the
system's state than I'd expected.

Andy, Blair, is this something that's worth fixing ?  Perhaps by making
#identifier and #fileLocator into read-only aspects if the Bitmap is shared ?

    -- chris

You can download it form here:
http://www.smalltalking.net/Goodies/Dolphin/index.htm

One problem I could not solve is translating from Bitmap to an icon group.
I mean being able to create an icon with differents sizes (32x32, 16x16)
from bitmaps, like we have loading from a file or resource.
I found more easy to maintain an application, particulary if you work with
graphic designers, if icons are not in separate files or resources. Having
all in a big bitmap, as in the old days, is easier.

Diego

DiegoC wrote:

> You can download it form here:
> http://www.smalltalking.net/Goodies/Dolphin/index.htm

Thank you.

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...

 [Re: Modifying a shared bitmap in an inspector]
>....
> Andy, Blair, is this something that's worth fixing ?  Perhaps by making
> #identifier and #fileLocator into read-only aspects if the Bitmap is
> shared ?


Yes, that would seem a sensible change, recorded as #1603.

Thanks

Blair