Error in deployed application

All,

my app is running fine in development environment and as deployed
executeable.

Just one window resists all tries to get it work in deployed app.

I get "UndefinedObject does not understand #viewNamed:ifNone:".

Anyone an idea?

The stack dump:

{0A33069C: cf 0A330679, sp 0A3306B0, bp 0A330694, ip 12,
MessageNotUnderstood class>>receiver:message:}
        receiver: MessageNotUnderstood
        arg[0]: nil
        arg[1]: Message selector: viewNamed:ifNone: arguments: #('rbJahre' [] @ 3
in UndefinedObject>>???'doIt' )

{0A330678: cf 0A330659, sp 0A33068C, bp 0A330674, ip 4,
Object>>doesNotUnderstand:}
        receiver: nil
        arg[0]: Message selector: viewNamed:ifNone: arguments: #('rbJahre' [] @ 3
in UndefinedObject>>???'doIt' )

{0A330658: cf 0A330625, sp 0A33066C, bp 0A330648, ip 17, [] in
BiPosIntervallDialog(Presenter)>>attachSubPresenterViews:}
        receiver: a BiPosIntervallDialog
        arg[0]: a BooleanPresenter
        stack temp[0]: nil
        stack temp[1]: 'rbJahre'

{0A330624: cf 0A330601, sp 0A330640, bp 0A33061C, ip 11,
OrderedCollection>>do:}
        receiver: a OrderedCollection
        arg[0]: [] @ 10 in Presenter>>attachSubPresenterViews:
        stack temp[0]: 1

{0A330600: cf 0A3305E1, sp 0A330614, bp 0A3305FC, ip 30,
BiPosIntervallDialog(Presenter)>>attachSubPresenterViews:}
        receiver: a BiPosIntervallDialog
        arg[0]: nil

{0A3305E0: cf 0A3305C1, sp 0A3305F4, bp 0A3305DC, ip 3,
BiPosIntervallDialog(Presenter)>>view:}
        receiver: a BiPosIntervallDialog
        arg[0]: nil

{0A3305C0: cf 0A3305A1, sp 0A3305D4, bp 0A3305BC, ip 4,
BiPosIntervallDialog(Shell)>>view:}
        receiver: a BiPosIntervallDialog
        arg[0]: nil

{0A3305A0: cf 0A330579, sp 0A3305B4, bp 0A330598, ip 17,
BiPosIntervallDialog(Shell)>>createView:}
        receiver: a BiPosIntervallDialog
        arg[0]: 'Frage_view'
        stack temp[0]: a DesktopView

{0A330578: cf 0A330555, sp 0A330590, bp 0A330570, ip 6,
BiPosIntervallDialog class(Presenter class)>>create:on:}
        receiver: BiPosIntervallDialog
        arg[0]: 'Frage_view'
        arg[1]: a BiPosIntervall

{0A330554: cf 0A330531, sp 0A330568, bp 0A33054C, ip 4,
BiPosIntervallDialog class(Dialog class)>>showModal:on:}
        receiver: BiPosIntervallDialog
        arg[0]: 'Frage_view'
        arg[1]: a BiPosIntervall

KlausK wrote:

> Just one window resists all tries to get it work in deployed app.
>
> I get "UndefinedObject does not understand #viewNamed:ifNone:".
>
> Anyone an idea?

It sounds as if the view resource BiPosIntervallDialog.'Frage_view' is not
loading correctly.  Maybe it has been stripped from your application ?  The
(new in D6) "Executable browser" should be able to tell you what views have
been left in the executable (although knowing /what/ has been stripped in only
the first step in finding out /why/...)

    -- chris

Hi,

first of all, thank you for answering, I allready thought that nobody is
interested in this...

I just found the reason! It is VERY srange!
I open the Dialog with:

darstellen
        | aString answer anIntervall aList intervallCount anIntervallSet
startDate endDate anObject groesse anCurve anDescriptionSet anDataSet |

        anIntervall := BiPosIntervall new.

        answer := BiPosIntervallDialog showModal: (BiPosIntervallDialog
frage_grob) on: anIntervall.

        answer ifNil: [^answer].

The class 'BiPosIntervallDialog' has one resource:
resource_Frage_view

The content of the method 'frage_grob'
frage_grob
        ^'Frage_view'

This works in development environment!!!

To get it working in deployed app one has to remove the underline!

frage_grob
        ^'Frage view'

Strange, very strange...

Cheers,
Klaus

Klaus,

> This works in development environment!!!
>
> To get it working in deployed app one has to remove the underline!

That is strange, and even rather funny (if you have a strange sense of humour
;-)

I /think/ what's happening is:

The new system in D6 stores view resources as methods.  Those methods have
names which are derived from the String name of the resource by replacing space
with _ and then discarding any illegal characters.  As a result a lookup string
with "wrong" underscores instead of spaces (or with extra illegal characters)
will work, even in a deployed image.

When the image stripper attempts to remove unnecessary view resources, it looks
for literal Strings which name a view resource, and doesn't remove the named
resource.  But since it is looking for literal strings which are /exactly/ the
same as the name of a view resource, it doesn't "realise" that your code using
the string 'Frage_view' will attempt to find the resource named 'Frage view'.
So it removes that resource.

So your code fails at runtime.  But only in when deployed.

I'm inclined to call this a bug in Dolphin (either the image stripper should
know how to compare view names correctly, or -- much better -- the view name
<-> method name mapping algorithm should be 1-to-1 so that /every/ String would
have a unique encoding as a method name).  Still, I wouldn't bet much on the
chance that Andy or Blair will agree, or give it high priority even if they do
;-)

    -- chris

Chris,

frends call my kind of humor 'very' strange, so I am able to smile on
this...

I agree with your theory in first part. There is some code that translates
the name of the view into the method name, but I don't think the
image-stripper eleminates the 'resource_Frage_view'. This would allways
lead into trouble if someone computes the name of the target resource.

I think the logic of translation is different in development and deployed
runtime.

Cheers,
Klaus

Klaus,

> I agree with your theory in first part. There is some code that translates
> the name of the view into the method name, but I don't think the
> image-stripper eleminates the 'resource_Frage_view'. This would allways
> lead into trouble if someone computes the name of the target resource.

You might find it interesting to read the comments in the method
ImageStripper>>resourcesForClasses:  ;-)

Ultimately, the point is that the automatic dependency discovery is not
intended to be 100% perfect -- that would probably be impossible.  It's just a
framework which will do most of the work for you, and which you can extend
if/when you have to.

    -- chris