Odd ListPresenter behaviour in deployed application...

I have a simple GUI which contains a ListPresenter on an OrderCollection.

When I run this from the image its fine, but when I run it from a
deployed executable the ListPresenter just displays one entry with:
"anOrderedCollection( xxx, xxx, xxx, xxx ) instead of each item.

Has something been prematurely stripped here?

Mark,

> I have a simple GUI which contains a ListPresenter on an OrderCollection.
>
> When I run this from the image its fine, but when I run it from a
> deployed executable the ListPresenter just displays one entry with:
> "anOrderedCollection( xxx, xxx, xxx, xxx ) instead of each item.
>
> Has something been prematurely stripped here?

It could be a #printOn: or similar method.  If you still have method
stripping disabled, then it seems likely that a package was removed, taking
the method with it.  If that is the case, a manual prerequisite might be the
answer.

However, I am also suspicious that you have an incorrect model.  One
interpretation of your report is that you have a collection in which the
first element is a collection that was intended to be the contents of your
list presenter.  Do you perhaps use one of #show and #showOn: in development
and the other in your deployed executable?  If so, look at your presenter's
#defaultModel as well as the explicit model that you set - they might not
have the same shape.

BTW, I strongly encourage you to "ride this out".  Deployment can be a
little frustrating in the beginning, as can other aspects of Smalltalk, but
the benefits soon start to exceed the problems.

Have a good one,

Bill

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

Bill Schwab wrote:

> However, I am also suspicious that you have an incorrect model.  One
> interpretation of your report is that you have a collection in which the
> first element is a collection that was intended to be the contents of your

That seemed to be the problem.  Following what I read at:

http://www.object-arts.com/EducationCentre/Tutorials/CreatingTheDomainModels.htm

I had:

   recipients := ListModel with: OrderedCollection new.

in my initialize method.  Making this return directlly the
OrderedCollection seemed to solve the problem.

> list presenter.  Do you perhaps use one of #show and #showOn: in development
> and the other in your deployed executable?  If so, look at your presenter's

I was calling "show" with the default model in each instance, which
makes this stranger.

> BTW, I strongly encourage you to "ride this out".  Deployment can be a
> little frustrating in the beginning, as can other aspects of Smalltalk, but
> the benefits soon start to exceed the problems.

Yep, the more I use it the more I like it.  We're still not sure we
really want to go down the road of a windows app and supporting it
ourselves ( we're more back-end services/java ) but if we do, I think
I'll be pushing for a Dolphin licence, even thou we already have MSDN...

Now I just need to work out some other things we need this app to do (
SOAP/WebServices, and register as a COM component ).

Mark Derricutt wrote:

>    recipients := ListModel with: OrderedCollection new.

I think the problem may be the use of ListModel class>>with:, which is
deprecated.

The "correct" selector to use to create a ListModel wrapped around some other
collection is #on:

    recipients := ListModel on: OrderedCollection new.

(BTW, a #new ListModel uses an OrderedCollection by default, so that could be
written more simply, if less transparently, as:

    recipients := ListModel new.

.)


Now, #with is deprecated, and is in the 'Dolphin MVP (Deprecated)' package.  It
seems likely that that package will be removed as part of stripping (I think
there's a setting to control that, but can't remember off-hand).  If so then
the implementation of #with: will be inherited from the superclass. Collection,
where it's implementation is to answer a new collection with the parameter as
its first element.  (Which, of course, means that #with: was a badly chosen
selector for creating ListModels, and is presumably why it's been deprecated.)

I suspect that if you fix this, then your app will work correctly again.  I
/suspect/ that not creating the ListModel at all (which is how I read your
post) will cause problems: the ListPresenter/ListView (and similar) components
can work with an OrderedCollection as their model, but only in very limited
ways -- the list must be completely static for instance -- and they really
/need/ a ListModel to work properly.

    -- chris

Mark,

That seems strange to me, because the "shape" should be the same.  It
makes me wonder whether you are getting into trouble by changing the
model.  Generally, it is better to retain the model of an MVP triad,
which in the case of list presenters, is a ListModel.  See ListModel>>list:.



> Yep, the more I use it the more I like it.  We're still not sure we
> really want to go down the road of a windows app and supporting it
> ourselves ( we're more back-end services/java ) but if we do, I think
> I'll be pushing for a Dolphin licence, even thou we already have MSDN...

At present, Dolphin is about the only thing keeping me on Windows - it's
that good.


> Now I just need to work out some other things we need this app to do (
> SOAP/WebServices,

Check out Dolphin Harbor, and probably others.


 > and register as a COM component ).

This is possible, unless you need something that is free threaded, which
I believe is beyond Dolphin's capabilities.  Dolphin can run in-process,
and as an exe server.

With respect to COM, I recommend asking yourself whether or not you
really need it.  If you can write your specs in terms of IPC vs. COM,
use sockets, and skip a lot of hassels.  If you genuinely need COM, have
at it.

Have a good one,

Bill

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

Chris,

> Now, #with is deprecated, and is in the 'Dolphin MVP (Deprecated)' package.  It
> seems likely that that package will be removed as part of stripping (I think
> there's a setting to control that, but can't remember off-hand).  If so then
> the implementation of #with: will be inherited from the superclass. Collection,
> where it's implementation is to answer a new collection with the parameter as
> its first element.  (Which, of course, means that #with: was a badly chosen
> selector for creating ListModels, and is presumably why it's been deprecated.)

That is probably it.  Nice sleuthing!

Have a good one,

Bill

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