Toolbar troubles - deployment

Hi folks,
I'm having some problems with toolbars in a deployed application.
Everything works fine in the development environment, so I'm thinking
I'm not stripping properly, but have been unable to track down the
problem.

Basically, I have 2 toolbars for the shellview I'm using. This first
one is the standard "file" toolbar from OA; the 2nd toolbar has a
couple of my own toolbar icons. I've copied the appropriate resources
I'm using into the GUIToGo.exe stub using ResHack, and double-checked
they are indeed there with XN Resource Editor.

However, when I deploy, this weirdness occurs: some of the buttons in
my 2nd toolbar show the icons from toolbar 1. In fact, the first two
icon buttons on my 2nd toolbar are the last two icon buttons from the
file toolbar! This has the strange effect of shifting *all* of my icon
graphics for application such that icons for certain classes render
alternate icons not of my choosing...

It's 04:00 east-coast USA, so I hope I'm not just rambling, and am
making some semblance of sense here...
Does anyone have thoughts or tips? Again, everything works fine in the
development image, so I'm figuring I've screwed up deployment somehow,
but just can't see it...

Thanks!

Keith

Keith,

> However, when I deploy, this weirdness occurs: some of the buttons in
> my 2nd toolbar show the icons from toolbar 1. In fact, the first two
> icon buttons on my 2nd toolbar are the last two icon buttons from the
> file toolbar! This has the strange effect of shifting *all* of my icon
> graphics for application such that icons for certain classes render
> alternate icons not of my choosing...

That sounds very wierd, and I don't have a sensible suggestion as to what might
be causing it.  Some questions to check the basics.

Have told Dolphin that it should look in the .EXE for resources ?  I use an
override of #defaltResLibPath in my apps' SessionManagers which just does:

    ^ self argv first.

(Why the system doesn't do this by default is beyond me, or better to make
non-development images definitions of SessionManager>>defaultResourceLibrary
answer nil, which would have (I believe) the same effect but in a more
controlled manner.)

Are you using D5 or D6 ?  There have been some changes to the toolsbars which
might be relevant.

Last question: what names did you use for the resources ?

    -- chris

Hi Chris,
Thanks for the pointers.
I'm using D6, with the latest patches applied.
I've already overridden the #defaultResLibPath (I'm learning -- you and
a few other people had posts about this is the past, so that was the
first thing I did :-) :-) )

I'm naming my resources things like 'play.ico', so both the runtime and
the development image can locate them using Icon fromId:

The funny thing is that this was working okay at one point last week. I
recently did a "panic" to make sure I didn't have any dead object
floating around the system, and then the wierdness began. Is it
possible that the view resource has been corrupted in some way? (but if
so, wouldn't the problem also show up in development mode????)

Still can't wrap my head around this one...

Other thoughts/insights?

Keith

Chris and Keith,
"Chris Uppal" <[hidden email]> wrote in message
news:43fef74c$0$1173$[hidden email]...
[...]
> Have told Dolphin that it should look in the .EXE for resources ?  I use
> an
> override of #defaltResLibPath in my apps' SessionManagers which just does:
>
>    ^ self argv first.
[...]
I'd recommend this for #defaultResLibPath instead:

    ^self imageFileName

I've run into two problems using "self argv first":
    - It doesn't work for DLLs
    - It doesn't always have a complete filename

The DLL issue came up a couple of years ago, and, IIRC, again sometime
during the beta or early in the initial release of Dolphin 6.  Blair's
contention was that, for obvious reasons, it doesn't make sense for a DLL to
try to access #argv.

The second case is a little more obscure, but if (1) you've incorporated
your icons into the executable file (i.e., the stub used for deployment),
and (2) you start the executable from the command line without specifying
its extension, ExternalLibrary will append a 'DLL' extension to your
program's name and try to open that as the resource library.

Maybe just answering nil in runtime SessionManager subclasses would avoid
these problems, but I don't know.

FWIW,

Don

Thanks Don,
If changed the #defaultResLibPath as you suggested, without success.
After more experimentation, here's what I've found:
1. I removed *both* toolbars from my view to see if I was introducing
problems there. All my other button icons seem to be rendering
properly. However, in my TreeView, the icons for my 3 core classes are
still screwed up in the deployed image. I'm suspecting this is the
source of my problem but...

Here are the class side methods I have for overridding the icons for
the classes (basically followed a similar pattern that OA used)
icon
        ^##(self) defaultIcon

defaultIcon
        ^SessionManager current isRuntime
                ifTrue: [ Icon fromFile: 'icon_smallbulb.ico' ]
                ifFalse: [Icon fromFile: 'resources\icon_smallbulb.ico'].

For the defaultIcon method, I've tried both the #fromFile: and #fromId:
methods with the same results. In effect, everything renders fine in
the development image, but in deployment, either the wrong icon is
displayed for these classes, or *no* icon is displayed at all. In my
session manager, I set resourceLibrary to nil, hoping that will force
the system to read the resources from the .exe, but no luck. Am I
missing a step here??? I think once I get the class icons to render
properly, I'll be halfway there to solving the mystery.....

Keith

Keith,
"keith" <[hidden email]> wrote in message
news:[hidden email]...
[...]
> icon
> ^##(self) defaultIcon
[...]
Which class did you do this on?  Is it on the class side of each of the
classes you're putting in the tree view, or is it on a superclass?  Forgive
me if you already knew this, but the "##(self)" construct ensures that the
method always refers to the class in which it is defined.  That's pretty
much guaranteed to produce unexpected results if you start using it without
knowing that.

I think OA has done a great job with the simplest kind of deployment.  It's
pretty straightforward if you don't mess around with the defaultResLibPath,
and just put your custom ICO files (and maybe DolphinDR006.dll if you need
Dolphin icons) in the same directory as your executable file.  If you want
to roll everything into a single executable file, it can be a bit
frustrating.

I don't know whether there are any quirks hiding in the D6 deployment
process that might affect this, as I'm only just now getting round to
deploying a D6 version of one of our applications.   It is the next thing I
have to do today, so maybe I'll run into something.

I know that some of what I did when I first got this sort of thing working
in D5 should be excised from my D6 code (and probably from all of human
history if possible), but I'll know more as the day progresses.

HTH,

Don

Thanks again for taking time to help me through this...I must admit
that I'm still feeling my way through and learning, so I'm sure I've
made my share of dumb errors here. Having said that, I apologize in
advance for any silly/obvious questions I'm about to ask below....

I used the ##(self) construct on the class side of *each* of the
classes I described, so I *think* that should work okay, right?
Basically, each class has its own icon I want to display.

I think I've narrowed things down to the TreeView itself - and my
ignorance with using it. I've lacking some understanding in the
#getImageBlock: setting from the view composer -- originally I left
everything the default -- [] in
IconicListAbstract>>defaultGetImageBlock. This shows the icons
correctly in the development image, but not in the deployment. I then
set #getImageBlock: to nil, and it doesn't work in either.

So....my question: for TreeViews, what should I be looking to set here?
Apparently, the default returns an index to the image resource (which,
I'm assuming is not in my stub), so how do I set this appropriately so
the TreeView uses the image resources I've inserted in the GUIToGo
stub, and make sure they correspond to the actual class icons I've
provided?

Thanks,

Keith

Keith,

BTW, something you said in another post suggested that you might not be
deploying from a completely clean image.  That's not a good idea -- as I've
said many times before ;-)


> defaultIcon
>  ^SessionManager current isRuntime
>    ifTrue: [ Icon fromFile: 'icon_smallbulb.ico' ]
>    ifFalse: [Icon fromFile: 'resources\icon_smallbulb.ico'].

I think that might cause problems.   The problem (if my suspicion is correct)
is that you may or will end up with instances of Icon in your deployed
executable (possibly hidden inside View Resources) which refer to the
'resources\icon_smallbulb.ico' name.

There are various ways around that, most of which are fairly messy.  The least
messy I know of is to define a special kind of ResourceLocator which knows
about the conventions you are using.

I recently added PackageResourceLocator to the 'CU Package-relative File
Locator' package on my website.  You might find it useful directly or as an
example.  With it you can say:
    locator := PackageResourceLocator package: somePackage.
    icon := Icon fromFile: 'MyIcon.ico' usingLocator: locator.
The point is that the locator considers a resource with an ID of:
    'MyIcon.ico'
to live in a file called:
     'Resources\MyIcon.ico'
So, when the system tries to load the resource, it'll first try in the
application's resource segment under the name:
    'MyIcon.ico'
but if that fails then it'll look for a file called
    'Resources\MyIcon.ico'
relative to the application (or to the package in a development image).

That stuff is in the Miscellanea page of
http://www.metagnostic.org/DolphinSmalltalk/.  Unfortunately (for you) the
package also includes PackageRelativeFileLocator, which is now included in the
base system, so you'll have to be a little careful how you load it (assuming
you wish to).

    -- chris

Don,

> I'd recommend this for #defaultResLibPath instead:
>
>     ^self imageFileName
>
> I've run into two problems using "self argv first":
>     - It doesn't work for DLLs
>     - It doesn't always have a complete filename

Sounds reasonable.  I'll try changing my stuff too.

Though I stll think (without having checked it) that the best solution is for
#defaultResourceLibrary to answer nil, since that would leave the whole thing
up to Windows.

Although, come to think of it, I don't know what it would do for a DLL
deployment. Would Windows look in the DLL or the containing .EXE ?  Hmm...

    -- chris

Chris,
"Chris Uppal" <[hidden email]> wrote in message
news:43ff61a4$1$1171$[hidden email]...
[...]
> Though I stll think (without having checked it) that the best solution is
> for
> #defaultResourceLibrary to answer nil, since that would leave the whole
> thing
> up to Windows.

>
> Although, come to think of it, I don't know what it would do for a DLL
> deployment. Would Windows look in the DLL or the containing .EXE ?  Hmm...
>
>    -- chris
>

There may well be something I don't see in this process, but it looks like
nil would just get passed through to ExternalResourceLibrary in
SessionManager>>defaultResourceLibrary.  From a quick glance at the
ExternalResourceLibrary method (#open:withAliases:flags:), it doesn't look
like it would be happy with nil.

Don

Keith,
"keith" <[hidden email]> wrote in message
news:[hidden email]...
> Thanks again for taking time to help me through this...I must admit
> that I'm still feeling my way through and learning, so I'm sure I've
> made my share of dumb errors here. Having said that, I apologize in
> advance for any silly/obvious questions I'm about to ask below....
Asking a silly or obvious question minimizes the burden of answering it ;^).
Besides, this sort of thing, while it may turn out to be simple, isn't
necessarily obvious.

>
> I used the ##(self) construct on the class side of *each* of the
> classes I described, so I *think* that should work okay, right?
> Basically, each class has its own icon I want to display.
Seems right.

>
> I think I've narrowed things down to the TreeView itself - and my
> ignorance with using it. I've lacking some understanding in the
> #getImageBlock: setting from the view composer -- originally I left
> everything the default -- [] in
> IconicListAbstract>>defaultGetImageBlock. This shows the icons
> correctly in the development image, but not in the deployment. I then
> set #getImageBlock: to nil, and it doesn't work in either.
In my image (Dolphin Pro 6.02), the getImageBlock in TreeViews defaults to
the IconicListAbstract class; if you don't understand how that works, don't
worry about it for now, but just set it back to IconicListAbstract (type the
name into the workspace and press CTRL-S to save it).

When things behave differently at runtime, one of the first things to check
is whether something got stripped out during deployment.  To do that, you
need to look at the image stripper log, which, in D6, is simplest with the
Executable Browser.  There you can see whether your classes' #icon methods
still exist in the executable file.  If they don't, just add them to the
"must not strip" category, and redeploy your app.  (If you haven't
categorized methods yet: right-click on the method, click "add to category",
and find "must not strip".)

>
> So....my question: for TreeViews, what should I be looking to set here?
> Apparently, the default returns an index to the image resource (which,
> I'm assuming is not in my stub), so how do I set this appropriately so
> the TreeView uses the image resources I've inserted in the GUIToGo
> stub, and make sure they correspond to the actual class icons I've
> provided?
Hopefully that's not where the problem is, but keep us posted on your
progress.

HTH,

Don

>
> Thanks,
>
> Keith
>

Don,

> There may well be something I don't see in this process, but it looks like
> nil would just get passed through to ExternalResourceLibrary in
> SessionManager>>defaultResourceLibrary.  From a quick glance at the
> ExternalResourceLibrary method (#open:withAliases:flags:), it doesn't look
> like it would be happy with nil.

I meant that #defaultResourceLibrary itself should return nil.  That should end
up with 0 being used as the handle of the "module" where we ask Windows to find
the resource.

Mind you, I haven't actually /tried/ this ;-)

    -- chris

Thanks Chris,
I'll have to take a look at your stuff...I guess my one question is
that I thought the Icon fromId: and Icon fromFile: would find the
resources appropriately *without* having to go through gyrations of
setting up locators and such. Was my assumption wrong?

You're right -- I've been a bad boy and haven't deployed from a clean
image, which could be the root cause of my problem. So, that'll be the
first thing I address.
(the image manager returns an index for my icons that don't match the
ones in my GuiToGo stub)

Thanks for the pointers

Keith

Good points!
Thanks again for the assistance. I'll examine the deployment log, make
sure that I'm deploying from a clean image, and let you know how things
turn out....

Keith

keith wrote:

> I'll have to take a look at your stuff...I guess my one question is
> that I thought the Icon fromId: and Icon fromFile: would find the
> resources appropriately *without* having to go through gyrations of
> setting up locators and such. Was my assumption wrong?

I think it's more that the design of the locators isn't as obvious as it might
be.  As I see it, the idea is that the string which the locator looks for is
supposed to be a valid resource name, and that it's the job of the locator to
turn that into a filename if necessary.  Since Windows has restrictions on the
names that one can use for resources (and expect it to work), so do Dolphin's
resource locators.

I think what makes it confusing is that you can give a resource name like
    blah\MyClass.ico
or:
    C:\blah\blah\MyClass.ico
to a locator and it will find the /file/ perfectly well, which rather obscures
the way that the locators are supposed to work.

    -- chris

Chris,
"Chris Uppal" <[hidden email]> wrote in message
news:4400274e$2$1168$[hidden email]... Oh, yeah, that *would* be different.   Never mind ;^).

> up with 0 being used as the handle of the "module" where we ask Windows to
> find
> the resource.
>
> Mind you, I haven't actually /tried/ this ;-)
Having just deployed an otherwise functional app, I wonder what would happen
if someone were to change its SessionManager subclass so that
#defaultResourceLibrary *did* return nil...

Don

>
>    -- chris
>
>
>

Thanks again Don and Chris for all your help with this...looks like
things have been resolved with your assistance.
Chris - you were absolutely right about deploying from a clean image.
Wow, I never realized just how important this was! After restoring the
IconicListAbstract as Don suggested, and deploying from a clean image -
bingo...everything worked as expected. Another key lesson learned for a
newbie from a file-based world...
Again, thanks immensely for your help & suggestions!

Keith

Don,

> > up with 0 being used as the handle of the "module" where we ask Windows
> > to find
> > the resource.
> >
> > Mind you, I haven't actually /tried/ this ;-)
> Having just deployed an otherwise functional app, I wonder what would
> happen if someone were to change its SessionManager subclass so that
> #defaultResourceLibrary *did* return nil...

I have tried it now, and it doesn't work :-(  I haven't worked through the
details, but it seems to be something to do with the way that Images (Bitmap,
Icon, etc) overload their "instanceHandle" to detect whether they are
initialised (nil therefore being interpreted as "I'm not initialised" rather
than "I load me data from the .exe").

    -- chris

After a couple of weeks, I've noticed one bit more weirdness:
I can deploy from a clean image, install on a different machine (or
vmware), and everything displays as expected. However, when I take the
*exact* same application and try to run in on my development machine,
I'm back to getting the shifted icons. This happens even when I'm *not*
running the Dolphin development image! For some reason, the icon
imageList is shifted by some number (although when running inside the
development image, everything is fine). Any thoughts? I was under the
impression that Icon #fromId:  would search the .exe stub *first*
before seeking on disk; but methinks the reverse is happening for me...

Keith

keith,

> After a couple of weeks, I've noticed one bit more weirdness:
> I can deploy from a clean image, install on a different machine (or
> vmware), and everything displays as expected. However, when I take the
> *exact* same application and try to run in on my development machine,
> I'm back to getting the shifted icons.

Are you still using the answer-different-Icon-if-in-development-image trick ?
If so then, as I said before, I don't think it'll work:

===== quote from previous post ====
> defaultIcon
>  ^SessionManager current isRuntime
>    ifTrue: [ Icon fromFile: 'icon_smallbulb.ico' ]
>    ifFalse: [Icon fromFile: 'resources\icon_smallbulb.ico'].

I think that might cause problems.   The problem (if my suspicion is correct)
is that you may or will end up with instances of Icon in your deployed
executable (possibly hidden inside View Resources) which refer to the
'resources\icon_smallbulb.ico' name.

There are various ways around that, most of which are fairly messy.  The least
messy I know of is to define a special kind of ResourceLocator which knows
about the conventions you are using.
========= end quote =========

If not (or even if you are and are interested) then you could add some logging
to your application to record the exact details of the icons' ids and
ResourceLocators (remember that the default #printString of Icon and
ResourceLocators do /not/ provide enough information to identify what's going
on).

    -- chris