Re: Getting started with Icons?

Hey that was awesome - thanks for the description.

So I think I am still with you in understanding - however what happens in
the View Composer if you place a PushButton - To Toggle, and put an
expression in the Image aspect?

I was hacking the default view for the System Browser - and figured the Icon
fromId: would coincide with the icons in DolphinDR005.DLL but I cant' make
heads or tails of what the ID numbers mean - all the icon viewers I use give
numbers that when I use them in the compser just give me an exclamation mark
icon (which I think means it didnt find anything).

For some random numbers that work - it also seems pretty random what icon
size gets put in my button. If I use the string variation - and use a name
that my resource viewer (e.g. ResHacker) shows - again its not clear what
size icon will display. My button is 16x16 but I have no idea how to get
that sized icon into my button...

Its all a bit of a mystery - but I think I'm almost there in
understanding...

Does this ring any bells with anyone else?

Tim

"Chris Uppal" <chris.uppal@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:433c2403$0$38038$bed64819@xxxxxxxxxxxxxxxxxxxx
> TimM wrote:
>
>> If I want to add a pushbutton with an Icon to one of the existing
>> Dolphin browsers - how do I get started in uderstanding how Icon's
>> work?
>
> I find the whole field pretty confusing (mostly MS's fault) and have yet
> to
> find a good overview. The MS documentation simply stinks. Even Petzold
> wasn't
> very much help.
>
> Here's my current (gappy) understanding. I hope that it's some help, or
> at
> least that someone else can fill in the gaps for both of us.
>
> The thing to realise is that Windows has two completely different ways of
> loading icons into a running program. One is to load them from a .ICO
> file;
> the other is to load them from the "resources" bound into some .EXE or
> .DLL
> (with the current program's .EXE as a special case of that). There are
> separate APIs for the two operations, and they don't even look similar to
> each
> other... (And, come to that, the actual binary layout of the Icon data is
> not
> quite the same in the two cases, which just makes things more "fun",
> though it
> shouldn't affect you unless you want to write an icon/resource editor.)
>
> (BTW, one of the reasons that Petzold wasn't very much help is that he
> seemed
> to concentrate on only the first of these, when the second is more common
> use -- at least in the Dolphin system.)
>
> Dolphin tries hard to hide this complexity, and does a good job for the
> most
> part. The downside is that the code gets pretty complicated, and it's
> hard to
> work out the underlying conventions that drive what's going on just from
> reading it. (There seem to be blizzards of FileLocators flashing around,
> most
> of which seem redundant, for instance.)
>
> Anyway, the way to create an Icon from a .ICO file is by an expression
> like:
>
> Icon fromFile: 'filename.ico' usingLocator: aFileLocator.
>
> where the FileLocator is an instance of one of the subclasses of
> FileLocator
> whose job is to turn a "relative" filename into something that the
> Window's OS
> can actually open. For instance there is a ImageRelativeFileLocator which
> interprets the name as if it were relative to the location of the image
> you are
> running. There are several other possible file locators you can use, or
> you
> can write your own.
>
> A slightly simpler form of the above is:
>
> Icon fromFile: 'filename.ico'.
>
> which is just the same except that it will use the default locator, which
> is an
> ImageRelativeFileLocator. If you provide an absolute pathname then the
> ImageRelativeFileLocator won't change what you've given it at all, so you
> can
> say things like:
>
> Icon fromFile: 'C:\Somewhere\filename.ico'.
>
> and that will work wherever the image was placed.
>
> As an aside, Icon>>printOn: produces confusing output since it /looks/
> like a
> valid Icon creation expression (indeed it is valid -- just wrong), but the
> expression doesn't reflect the FileLocator that is actually in use.
>
> The alternative method of loading icons is from the resources compiled
> into a
> DLL (or .EXE). Here the fully general creation expression is something
> like:
>
> Icon fromId: 134 in: ShellLibrary default.
>
> Here you give an "id" which can be either a String or an Integer to find
> the
> correspondingly named icon resource in an instance of ExternalLibrary.
> ExternalLibraries are normally used for wrapping access to another DLL's
> code,
> not just for loading icons, so you may well want to load icons from some
> arbitrary DLL (or .EXE) that doesn't already have a corresponding
> ExternalLibrary subclass. The special subclass ExternalResourceLibrary is
> intended to cover that case. You can say things like:
>
> notepad := ExternalResourceLibrary open:
> 'C:\Windows\system32\notepad.exe'.
> icon := Icon fromId: 2 in: notepad.
> notepad close.
>
> A couple of special cases. One is that if you miss off the library:
>
> Icon fromId: 428.
>
> or:
>
> Icon fromId: 'ASPECTBUFFER.ICO'.
>
> then Dolphin will look in the current SessionManager's #defaultResLibPath.
> By
> default that just points to the DolphinDR005.DLL resource DLL -- which
> isn't
> much use for deployed .exes unless you also ship that DLL with your
> application. It's normal to override that method to answer something like:
>
> defaultResLibPath
> ^ self argv first.
>
> in your applications' custom SessionManagers.
>
> A second special case is that you can provide nil as the ResourceLibrary,
> which
> is interpreted (by Windows) as a request to load resources from the
> current
> application's .exe. E.g:
>
> Icon fromId: '!APPLICATION' in: nil
>
> finds the application's "main" icon.
>
> Right; that's about it for how to load them.
>
> The next step is to realise that "an" Icon is actually a list of separate
> images of varying sizes and colour depths. As far as I can tell the
> "system"
> is supposed to handle all this for you -- if you use an Icon in a context
> that
> expects a 32x32x8-bit icon, then the system will try to find the best
> match
> from the cluster of images "in" that icon. How that happens, or even
> whether
> it works properly, is beyond me at the moment. Someday I may work it out,
> but
> not yet...
>
> When you are talking about loading "an" icon from a resource in a DLL
> there is
> also the possibility that there will be several options for different
> languages
> (perhaps not /very/ likely for icons, but still possible). As far as
> selecting
> the "right" icon for a user's language is concerned, I believe that
> Windows is
> supposed to handle all that for you -- if you ask for an Icon named 'FRED'
> and
> there are several possibilities (for different languages) in the same DLL
> then
> Windows will choose the right one for you. (Or that's what I /think/ is
> supposed to happen anyway).
>
>
> That was too long. Sigh...
>
> -- chris
>
>


.