Why can't I run my Dolphin executable on other machines?

Hello All

I would be grateful for advice on how to track down a problem. I have an
application which I have packaged as a Dolphin executable using D5.1.4, and
it runs fine on my main machine, which also has the D5 development system
installed. I have tried to run it on my second machine, which has never seen
a Smalltalk program; I copied the .exe file, the resource file
DolphinDR005.dll and the manifest file to a new folder under 'My Documents'
and double clicked the .exe. The main window opens, and many of the
functions will work, but I am getting a number of error message boxes saying
'UndefinedObject does not understand #method'. As an experiment I installed
D5 on the second machine and tried again; the program ran perfectly. I
uninstalled D5, and the error messages returned. Clearly the program is
accessing some D5 component other than the resource file, but I cannot work
out what.

Because the program is writing out an error file, I am able to see pretty
clearly where in the program the error is occurring. It is writing data to a
multi-column ListView, and I had a lot of trouble getting this to work
originally. After a discussion with Chris Uppal, I have some code which
generates a bit of Smalltalk source and then evaluates it; after the code
generation the line which leads to the DNU reads:
col getContentsBlock: (Compiler evaluate: '[:item| item at: 1]').
where the temporary variable 'col' refers to a column of the ListView; this
goes through a number of other Compiler class methods and gets to the DNU.
Does the fact that I am using the compiler mean the executable has to refer
to some external resource? Is it some problem of too much stripping in
generating the executable?

As you can see, I am floundering. Any suggestions gratefully received.

--
Best wishes

Peter Kenny

Peter Kenny escribió:
Try:

col getContentsBlock: [:item| item at: 1]

Or add the Compiler DLL to your app directory.
May be you need more external resources.

You can try:
1- Copy all Dolphin resources to your app directory.
2- Try the executable.
3- Then you can remove it one by one to catch the problem.

regards bruno

Bruno
> Try:
>
> col getContentsBlock: [:item| item at: 1]

This just does not work, because all columns of the ListView finish up with
the same contents. If I could write it as [:item| item at: i], where i is
the column number, that would be OK, but that also makes all columns the
same, at least on D5.

>
> Or add the Compiler DLL to your app directory.

This sounds likely, but I can't find the compiler dll in my D5 directories.
What is its full name, please?

> May be you need more external resources.
>
> You can try:
> 1- Copy all Dolphin resources to your app directory.
> 2- Try the executable.
> 3- Then you can remove it one by one to catch the problem.

I guess as a last resort I shall try this, but I was hoping to pick other
people's brains to avoid it.

Thanks

Peter

Peter,
>
>
> This sounds likely, but I can't find the compiler dll in my D5 directories.
> What is its full name, please?

In my machine:
C:\Archivos de programa\Archivos comunes\Object Arts\Dolphin Smalltalk 5.1

In English:
C:\Programs Files\Commons Files\Object Arts\Dolphin Smalltalk 5.1

Regards Bruno

"Bruno" <[hidden email]> wrote in message
news:[hidden email]...
Bruno

Many thanks. I put the compiler .dll with the app, and that fixed the
problem. I may try to find a way of removing the need for it, using another
route that Chris Uppal suggested, but for now all is OK.

Thanks again

Peter

Peter Kenny wrote:
>>Try:
>>
>>col getContentsBlock: [:item| item at: 1]
>
>
> This just does not work, because all columns of the ListView finish up with
> the same contents. If I could write it as [:item| item at: i], where i is
> the column number, that would be OK, but that also makes all columns the
> same, at least on D5.
Are you using the variable "item" somewhere else in that method? This
would explain why the all reference the same content.

You could try to use the following:

col getContentsBlock: ##(Compiler evaluate: '[:item| item at: 1]').

This should leave a "Literal Block" in the Method with no references to
Compiler.

Regards,

Udo

"Udo Schneider" <[hidden email]> wrote:

> You could try to use the following:
>
> col getContentsBlock: ##(Compiler evaluate: '[:item| item at: 1]').
>
> This should leave a "Literal Block" in the Method with no references to
> Compiler.

Udo

Unfortunately, in trying to make my query brief, I left out details. The
problem is to give the first column the getContentsBlock [:item| item at:
1], the second one [:item| item at: 2], and so on. In my full code this is
done with:

col getContentsBlock: (Compiler evaluate: '[:item| item at: ', colind
printString, ']')

where colind is the index number of the column. I don't think your ##()
suggestion would work with this.

The shorter form I quoted originally is after substitution of the colind
value. I have not found any shorter way of doing this which works; any
obvious method ends up with all columns having the same contents (at least
on D5). Chris Uppal suggested using a separate method which returns the
appropriate block for each column, which apparently does work. I may now try
this, to avoid dependency on distributing the compiler .dll with my app.

Thanks

Peter

"Peter Kenny" <[hidden email]> wrote in message
news:[hidden email]...
Returning the block from a method is the recommended workaround in versions
of Dolphin before X6, because they implement Smalltalk-80 style blocks,
rather than full block closure semantics (as in X6). This will work well
enough in most circumstances, and is certainly to be preferred to using the
compiler to achieve the same effect.

Regards

Blair

"Support at Object Arts" <[hidden email]> wrote:
> Returning the block from a method is the recommended workaround in
> versions of Dolphin before X6, because they implement Smalltalk-80 style
> blocks, rather than full block closure semantics (as in X6). This will
> work well enough in most circumstances, and is certainly to be preferred
> to using the compiler to achieve the same effect.
>
> Regards
>
> Blair
Blair

This reinforces the advice from Chris. Thing is, by the time I got that
advice I had already coded the compiler-based hack and was too lazy to
change it (or maybe too nervous to disturb something which already worked).
I have now been bitten by my inertia, and I shall make the change.

Thanks.

Peter