Small request about Icons

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Small request about Icons

Chris Uppal-3
A couple of us have asked for ways to store icons in packages and the image
rather than external files, and I don't know what OA's plans are for that.
But if that isn't something that's going to appear in D5 then one small
change would make *my* life easier without it.

Is there any chance you could move the true and false icons into the main
DLL instead of the developer resource one ?   I find I quite often want to
use true/false indications in enhanced list views, and the true/false icons
are ideal, but they don't get included with a generated .EXE.

Or is that more difficult than it sounds ?

TIA, anyway.

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: Small request about Icons

Blair McGlashan
"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> A couple of us have asked for ways to store icons in packages and the
image
> rather than external files, and I don't know what OA's plans are for that.
> But if that isn't something that's going to appear in D5 then one small
> change would make *my* life easier without it.
>
> Is there any chance you could move the true and false icons into the main
> DLL instead of the developer resource one ?   I find I quite often want to
> use true/false indications in enhanced list views, and the true/false
icons
> are ideal, but they don't get included with a generated .EXE.
>
> Or is that more difficult than it sounds ?

No, in fact it is easy for you to do yourself, and that way you can include
whatever icons you need. Here's how:

1) Acquire a resource editor. Microangelo is a good shareware example. If
one has VC++ one can use that. Then there are freeware tools such as
"Resource Hacker" (ResHacker).
2) Extract the icons you need from DolphinDR005.dll (or some other source,
or paint them up) using the resource editor.
3) Make a copy of the the relevant "to go" stub (e.g. GUIToGo.exe).
4) Edit the copy of the stub using the resource editor, and add the icons,
giving them the id's used in the Dolphin image (we usually use a string ID
of the form "<class name>.ico", but this is primarily to allow the icon to
be overridden by a file of that name, and any string or integer id can be
used).
5) Configure the ImageStripper of the application package to use the custom
stub:
    - In beta 2: Subclass ImageStripper and override #stubFile/#stubFilePath
    - In beta 3: Inspect the properties of the package and drill down to the
ImageStripper (or use the 'Custom Options' button in the Lagoon wizard), and
set the stubFilePath aspect to the path to the custom stub (tip: Double
clicking the aspect opens a File browser dialog).

One can also replace/edit any of the standard resources such as the main
.exe icon, though it is not a good idea to delete things. Note that in D5 it
does not matter if the size of the stub is changed by editing the resources.

This should only be a few minutes work and need only be done once no matter
how many times the executable is deployed, though of course it will have to
be repeated if and when we issue new stubs (not a frequent occurrence).

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: Small request about Icons

Steve Alan Waring
Hi Blair,

Thanks for these instructions!

I was able to add an Icon to a ToGo stub and use it in the executable. I did
find that I needed to add a SessionManager that implemented:

#defaultResLibPath
^self argv first

Is this necessary or correct?

FWIW: I used the freeware program at:
http://rpi.net.au/~ajohnson/resourcehacker/

Thanks again, this will be very useful!
Steve


Reply | Threaded
Open this post in threaded view
|

Re: Small request about Icons

Blair McGlashan
"Steve Waring" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Blair,
>
> Thanks for these instructions!
>
> I was able to add an Icon to a ToGo stub and use it in the executable. I
did
> find that I needed to add a SessionManager that implemented:
>
> #defaultResLibPath
> ^self argv first
>
> Is this necessary or correct?

Hmmm, that is not the intention. The default resource library should be the
executable in a deployed app, but quick perusal of the SessionManager
hierarchy reveals that is unlikely to be the case :-).

I haved added to the bugs DB for investigation (#757), in the meantime your
workaround is "correct".

Regards

Blair