Suggestion for Lagoon: Identify an alternate Icon for final .exe

Friends,

First of all, I for one am delighted with the improvements contained in
Lagoon. It's a great leap forward for the product.

A suggestion: rather than assigning the balloon icon to the final .exe, it
would be nice if we could assign a custom icon to it. I asked about this a
few years back, and it was pointed out that with the aid of a tool like
MicroAngelo, one can assign a different icon to the .exe - but isn't that
silly ? Each time we make a new .exe, we have to go through this process -
which is somewhat tedious and redundant.

Especially now, when Lagoon allows you to customize a packaging 'script' for
each package, being able to specify an icon would be a nice touch.

A related question: I notice that classes like NotepadSessionManager,
CalculatorSessionManager, etc. have icons which display in the class
browser, (but which do not appear in the final exe. - what a pity)  How are
their assigned to the class ? Other classes can implement a class-side
method called "icon", but these don appear to do the same.

Best wishes,

Ken Lee

Ken,


> A related question: I notice that classes like NotepadSessionManager,
> CalculatorSessionManager, etc. have icons which display in the class
> browser, (but which do not appear in the final exe. - what a pity)  How
are
> their assigned to the class ? Other classes can implement a class-side
> method called "icon", but these don appear to do the same.

They use the superclass implementation of RuntimeSessionManager class>>icon.
This just refers back to the #mainClassShell method which _is implemented in
each subclass.  I'm not sure why it was done that way - probably some subtle
reason to do with deploying?.

Ian

Hello all,

> > A related question: I notice that classes like NotepadSessionManager,
> > CalculatorSessionManager, etc. have icons which display in the class
> > browser, (but which do not appear in the final exe. - what a pity)  How
> are
> > their assigned to the class ? Other classes can implement a class-side
> > method called "icon", but these don appear to do the same.
>
> They use the superclass implementation of RuntimeSessionManager
class>>icon.
> This just refers back to the #mainClassShell method which _is implemented
in
> each subclass.  I'm not sure why it was done that way - probably some
subtle
> reason to do with deploying?.

I assumed the point was simply to give each session manager subclass the
"correct" icon, but, it could also be prelude to future improvements.  As
for getting the icon "into the executable", that's a potentially messy
problem.  <pedantMode>Technically, the icons are in the exe even
now</pedantMode>, but, they are not included as Windows resources and do not
replace with the beachball icon which is in the correct place to be
recognized as THE icon for the app.  Not long ago, Blair posted something
that would change the empty stub to agree with an icon set forcibly into a
deployed app (or was it just the empty stub??).

Getting Lagoon to change the icon itself would be a little tricky.  If it
does it after stipping, then (I think anyway) the code to do it will be
stuck in each deployed executable.  One way around that might be to have
either the VM or dev resources DLLs  export a function for the purpose; the
non-stripped overhead would then be fairly minimal.  Another possibility
might be to have Lagoon make a copy of the empty stub (perhaps called
workingStub.exe or something) that would have the new icon and needed
changes so as not to crash, and then deploy using it.

Finally, I keep thinking back to Borland's Resource Workshop, which at least
in the Windows 3.x era, was able to edit resources in binaries.  Personally,
I'd rather see the icon change automated as part of Lagoon, but, I could
find uses for a more general editor.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> I assumed the point was simply to give each session manager subclass the
> "correct" icon, but, it could also be prelude to future improvements.

It was just me not reading what I was looking at, if you see what I mean.  I
was reading the #mainShellClass method as answering the class that it
belonged to rather than the class that it was managing.

As you say, it just makes the SessionManager and the Class it manages
display the same icon.

Ian

Bill,

You're right. The reason we don't allow the EXE icon to be changed is simply
because it would be a fair amount of work to do it. We have to implement a
whole bunch of code that could read and write the various sections of the
PEF (Portable Executable Format) EXE files. At least we would for
applications deployed under Win9x. As it turns out NT and Win2K have an API
that would allow the resource section to be written fairly easily. Hence,
the ability to modify the icon almost crept into Dolphin 4 but for NT and
2000 deployment only!!!

Best Regards

Andy Bower
Dolphin Support
http://www.object-arts.com/Support.htm

Not all Addictions are Bad for you
http://www.object-arts.com/Addiction.htm

Bill Schwab <[hidden email]> wrote in message
news:91u493$5j8cq$[hidden email]...
> Hello all,
>
> > > A related question: I notice that classes like NotepadSessionManager,
> > > CalculatorSessionManager, etc. have icons which display in the class
> > > browser, (but which do not appear in the final exe. - what a pity)
How
> > are
> > > their assigned to the class ? Other classes can implement a class-side
> > > method called "icon", but these don appear to do the same.
> >
> > They use the superclass implementation of RuntimeSessionManager
> class>>icon.
> > This just refers back to the #mainClassShell method which _is
implemented not
> replace with the beachball icon which is in the correct place to be
> recognized as THE icon for the app.  Not long ago, Blair posted something
> that would change the empty stub to agree with an icon set forcibly into a
> deployed app (or was it just the empty stub??).
>
> Getting Lagoon to change the icon itself would be a little tricky.  If it
> does it after stipping, then (I think anyway) the code to do it will be
> stuck in each deployed executable.  One way around that might be to have
> either the VM or dev resources DLLs  export a function for the purpose;
the
> non-stripped overhead would then be fairly minimal.  Another possibility
> might be to have Lagoon make a copy of the empty stub (perhaps called
> workingStub.exe or something) that would have the new icon and needed
> changes so as not to crash, and then deploy using it.
>
> Finally, I keep thinking back to Borland's Resource Workshop, which at
least
> in the Windows 3.x era, was able to edit resources in binaries.
Personally,