Distributing a prototype Dolphin app

My Dolphin app is coming on well, and is nearing the point at which I would
like to demonstrate a prototype to potential users. I would like to clear up
a number of points, both technical and copyright issues, which will affect
how I do it. I would be glad of any advice, either from OA or from users who
have done something similar.

First thing is that I am still working with DVE, and using STB as a storage
vehicle between sessions. If I do get to the point of developing and
distributing a fully working system which can scale to real life situations,
I envisage upgrading to Dolphin Pro and using OmniBase as the storage
vehicle, so that I will distribute a fully stripped and packaged program.
However, getting Dolphin Pro and OmniBase will cost me $500 plus tax, and I
would prefer not to do that until I am surer of the market.

The first chance to demonstrate will come at conference next month, which is
on the other side of the Atlantic. I do not envisage lugging my own laptop
across, so I shall have a PowerPoint presentation on CD which I can run on a
borrowed machine. The ideal setup would be to have the Dolphin app on the
same CD, arranged so that it can run direct from the CD without any
installation on the host machine. At first sight this looks feasible, except
that Dolphin seems to expect to find components in specific locations such
as under c:\Program Files. Can it be set up to find the DLLs on  the CD? If
not, what is the minimum amount of installation I would have to do? Under
this scenario, the image would be the full Dolphin image, with no stripping,
but with a runtime session manager which boots straight into my app.
However, this would be for use only by me as a vehicle for demonstration,
not for distribution to others. As I understand it the Dolphin licence is
per user, not per machine, so I do not see any copyright issues.

However, the next stage could be to distribute copies of the prototype
program for investigation and comment by potential users. If the first
reactions are favourable there might be several cycles of prototyping and
feedback. So the question is how can I, with minimum effort and hassle, turn
my DVE image into something I can distribute without infringing Dolphin
copyright. At first sight, I thought of removing the three packages which
appear under the IDE folder in the Package Browser. That, coupled with the
runtime session manager, should ensure that nobody can  use the distributed
code to develop Smalltalk programs, which is the obvious limitation to
impose. Is this sufficient, or should I remove anything else? This is
covered rather sketchily in the Dolphin 4 help, but I would like to get more
detail. Is there any other material available? (I realised eventually that I
could not use the Package Browser to remove the packages, since it would try
to remove itself. I presume I can arrange to have them removed
programmatically the first time the runtime session manager executes.) The
obvious way to do this is also as a ready-to-run CD, with no installation; I
don't have time to master installers between now and the conference.

Just to emphasise I am not trying to get round Dolphin copyright in any way.
I want to do this at minimum cost and risk to myself, but I want to do it
legally, so I am setting out all the issues up front before I start
preparing for the conference.

Grateful for any comments or advice.

Peter Kenny

Peter,

> My Dolphin app is coming on well, and is nearing the point at which I would
> like to demonstrate a prototype to potential users. I would like to clear up
> a number of points, both technical and copyright issues, which will affect
> how I do it. I would be glad of any advice, either from OA or from users who
> have done something similar.

Generally, OA will grant permission to redistribute DLLs as needed to
make things run.  They will be more strict about the IDE itself, and you
clearly understand their reasons.


> The first chance to demonstrate will come at conference next month, which is
> on the other side of the Atlantic. I do not envisage lugging my own laptop
> across, so I shall have a PowerPoint presentation on CD which I can run on a
> borrowed machine. The ideal setup would be to have the Dolphin app on the
> same CD, arranged so that it can run direct from the CD without any
> installation on the host machine. At first sight this looks feasible, except
> that Dolphin seems to expect to find components in specific locations such
> as under c:\Program Files. Can it be set up to find the DLLs on  the CD?

I vaguely recall OA mentioning something about using autorun with a
deployed executable.  In a pinch, you could also auto-run an installer
that launches the program after installing it.


 > If
> not, what is the minimum amount of installation I would have to do?

That depends on what you use.  A minor annoyance in one Dolphin app can
keep another from starting.  I recommend taking the Dolphin IDE with you
just in case a particular machine presents a problem.  It's also a good
idea to have a CD with recent versions of IE, MDAC, web and database
servers, ODBC drivers, etc., depending on what you are doing.

Any time I pack for a trip, I start with burning a few copies of a
rescue CD.  My motto is "remember Chicago".  In that case, an MSVC CD,
that I had at first deliberately left behind and then decided to take,
saved my skin.


 > Under
> this scenario, the image would be the full Dolphin image, with no stripping,
> but with a runtime session manager which boots straight into my app.
> However, this would be for use only by me as a vehicle for demonstration,
> not for distribution to others. As I understand it the Dolphin licence is
> per user, not per machine, so I do not see any copyright issues.

FWIW, I suggest buying Dolphin Pro now.  I suspect that the time you
will save will justify the cost.


> However, the next stage could be to distribute copies of the prototype
> program for investigation and comment by potential users. If the first
> reactions are favourable there might be several cycles of prototyping and
> feedback. So the question is how can I, with minimum effort and hassle, turn
> my DVE image into something I can distribute without infringing Dolphin
> copyright.

Buy the pro edition and use Lagoon.  I recommend InnoSetup and ISTool
for creating end-user installations.


 > At first sight, I thought of removing the three packages which
> appear under the IDE folder in the Package Browser. That, coupled with the
> runtime session manager, should ensure that nobody can  use the distributed
> code to develop Smalltalk programs, which is the obvious limitation to
> impose. Is this sufficient, or should I remove anything else?

Buy the pro edition :)


 > This is
> covered rather sketchily in the Dolphin 4 help, but I would like to get more
> detail. Is there any other material available? (I realised eventually that I
> could not use the Package Browser to remove the packages, since it would try
> to remove itself. I presume I can arrange to have them removed
> programmatically the first time the runtime session manager executes.) The
> obvious way to do this is also as a ready-to-run CD, with no installation; I
> don't have time to master installers between now and the conference.

Stripping makes for some challenging debugging, and OA has done a
wonderful job of it.  Installers are not that bad to create, especially
with InnoSetup - it looks horrible, but that passes _very_ quickly once
you get going.


> Just to emphasise I am not trying to get round Dolphin copyright in any way.
> I want to do this at minimum cost and risk to myself, but I want to do it
> legally, so I am setting out all the issues up front before I start
> preparing for the conference.
>
> Grateful for any comments or advice.

Buy the pro edition :)  You won't regret it.

Have a good one,

Bill

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

"Peter Kenny" <[hidden email]> wrote in message
news:[hidden email]...
> My Dolphin app is coming on well, and is nearing the point at which I
would
> like to demonstrate a prototype to potential users. I would like to clear
up
> a number of points, both technical and copyright issues, which will affect
> how I do it. I would be glad of any advice, either from OA or from users
who
> have done something similar.
>
> First thing is that I am still working with DVE, and using STB as a
storage
> vehicle between sessions. If I do get to the point of developing and
> distributing a fully working system which can scale to real life
situations,
> I envisage upgrading to Dolphin Pro and using OmniBase as the storage
> vehicle, so that I will distribute a fully stripped and packaged program.
> However, getting Dolphin Pro and OmniBase will cost me $500 plus tax, and
I
> would prefer not to do that until I am surer of the market.
...

You could try getting a time limited trial of Dolphin Pro. Look here
http://www.object-arts.com/Trial/index.html .  It sounds like it would allow
you to deploy your application (though it too would be time limited).  If
you timed it just right the 30 days might allow you enough time to
demonstrate your program.

I assume you found this link
http://www.object-arts.com/Lib/EducationCentre4/htm/distributingadeployedimage.htm .
I am not sure if it would really be cost effective to spend the time
stripping a DVE yourself.  If time = money then at some point it will be
better to just buy Dolphin rather than trying to legally deploy from DVE.
It looks like there is a DVE to DPRO upgrade option that might only cost
~$309.

Good luck,
Chris

"Christopher J. Demers" <[hidden email]> wrote in
message news:[hidden email]...

>
> I assume you found this link
>
http://www.object-arts.com/Lib/EducationCentre4/htm/distributingadeployedimage.htm . Thanks Chris (and Bill Schwab) for the comments - I think I may persuade
myself that the cost of an upgrade to D Pro now is not too great, especially
when set against the cost of going to Canada for the conference. However,
this does not deal with the question whether I can set up my program
(whether from DVE or Pro) to run from the CD without installing anything on
the host machine. The link Chris cites suggests not - it implies that it is
essential to have the VM DLL in c:\Program Files\myApp and two MS DLLs in
c:\Windows\System32. This means it will be a bit more difficult to do a
demonstration - I have to  allow time to get the installation done and
verified, rather than just put the CD in the drive and set it running. Is
there such a thing as a ready-to-run CD version if I produce it using
Lagoon?

Thanks

Peter

Peter,

> Thanks Chris (and Bill Schwab) for the comments - I think I may persuade
> myself that the cost of an upgrade to D Pro now is not too great, especially
> when set against the cost of going to Canada for the conference.

Canada is a great place to visit, but they have the biggest mosquitoes I
have ever seen =:0


 > However,
> this does not deal with the question whether I can set up my program
> (whether from DVE or Pro) to run from the CD without installing anything on
> the host machine. The link Chris cites suggests not - it implies that it is
> essential to have the VM DLL in c:\Program Files\myApp and two MS DLLs in
> c:\Windows\System32. This means it will be a bit more difficult to do a
> demonstration - I have to  allow time to get the installation done and
> verified, rather than just put the CD in the drive and set it running. Is
> there such a thing as a ready-to-run CD version if I produce it using
> Lagoon?

A "ToGo" executable should not need the VM (it will be included as part
of the exe file), but it probably does have a couple of required DLLs
that are not always present; msvcp60.dll comes to mind.  I _think_ you
will find that MSVCIRT.DLL is no longer needed.

Worst case, I suspect you can use InnoSetup to install required files
and then launch your exe.  Regardless of whether it works at home, I
strongly urge that you take a rescue CD with you.

Good luck!

Bill


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

"Peter Kenny" <[hidden email]> wrote in message
news:[hidden email]...
It is not necessary to install anything on the host machine (unless you have
used external components that required installation). We gave out a stack of
Dolphin trial CDs* at a conference some years ago that had an autorun
executable
on them written in Dolphin itself. DPro includes the fundamentals of this as
an autorun sample. I've pasted the package comment below.

All of the DLLs can exist in the same directory as the deployed executable.
If you deploy as a ToGo executable (frankly there isn't much reason not to
do so) then you won't even need the VM DLL - just place the C runtime
library DLLs (MSVCRT.DLL and MSVCP60.DLL) in the root of the CD where the
autorun exe lives. In most cases you'll get away without those because they
are used by so many other programs that they are almost certainly on the
machine already, but to be sure put them on the CD because they don't take
much room.

Of course your autorun doesn't need to be a setup menu, you could launch
directly into the executable. To do that all you'd need would be to deploy
your application in ToGo mode, place it and the CRT DLLs on the CD, and then
write an autorun.inf to lauch it.

Regards

Blair

*I recall that before the conference started, we thought we'd better do a
final test that the CDs worked in our hotel room. We'd booked a room at the
Drake hotel in Chicago in order to enjoy a bit of R&R before the conference.
Unfortunately we felt rather uncomfortable even in the Drake when we
discovered that the CD didn't work. It spun up but the application would not
launch. We'd tried them at home before flying over, so we began to get
worried that they might have been damaged somehow in transit in the
aeroplane hold. Now starting to panic, we tried another, and that did work.
Phew! We decided that we would have to test every single one to sort out the
ones that worked from those that didn't. This took a few hours as I recall.
And do you know what? The only one which was faulty was the first one that
we had tried!

---------------------------
Dolphin Smalltalk Autoplay Sample.
Copyright (c) Object Arts Ltd, 2001-2002.

Autoplay is an application for use as a CD-ROM autoplay setup menu. As a
sample Autoplay demonstrates:
- Embedding the Microsoft Web Browser control in a Dolphin application (see
also the Simple Web Browser sample)
- How to prevent multiple instances of an application being started (see
AutoPlaySessionManager>>allowDuplicates)
- Simple command line processing (see AutoplaySessionManager>>main)
- Sizing a shell to precisely the right dimensions to fit a given client
area.

Although simple, Autoplay is capable of practical use, indeed Object Arts
used it for the Dolphin Pro Trial distributed at Smalltalk Solutions 2001,
and we will certainly use it again. Autoplay is now (as of Dolphin 5)
deployed in "ToGo" mode, and so does not require the Dolphin VM to run.
However to be sure that it will run on all machines, it is a good idea to
place the C runtime libraries (MSVCRT.DLL and MSVCP60.DLL) in the root
directory of the CD along with Autoplay.exe.

Autoplay can display a single page of HTML (specified by the first command
line argument, but defaulting to 'autorun.htm') at a specified fixed size
(specified by the second command line argument but defaulting to 480x480).
Normally this HTML file would contain little but an IMG tag and a map to
specify the location of links in the map. When the user clicks on the links
the HREF associated with the link is passed to the ShellExecute() API, the
result of which is to spawn off the appropriate application in another
window to open that particular type of file. This means that a separate
explorer window is opened to browse the CD (should that option be present)
and avoids the user being prompted to save/open the setup executable/MSI.

For example:

 <HTML>
   <HEAD>
     <TITLE>My Application</TITLE>
   </HEAD>
   <BODY scroll=no leftMargin=0 topMargin=0 bottomMargin=0 rightMargin=0>
     <MAP name="mymap">
       <AREA href="ReadMe.htm" shape="rect" coords="345, 147, 455, 169">
         <AREA href="setup.exe" shape="rect" coords="283, 174, 455, 197">
       <AREA href="./" shape="rect" coords="378, 266, 456, 286">
     </MAP>
     <IMG border="0" src="setupmenu.jpg" usemap="#mymap" width="480"
height="480">
   </BODY>
 </HTML>

The scroll and margin attributes associated with the BODY tag are important
to prevent the Web Browser Control displaying an unwanted scrollbar and
surrounding the graphic with a border of blank space. The areas in the map
respectively relate to the "Read Me", "Install XXX", and "Browse this CD"
links in the graphic.

CD-ROM Autoplay also requires an Autorun.inf file to be located in the root
directory of the CD-ROM. The content of this .inf file is of the following
format (for example):

 [autorun]
 OPEN=autoplay.exe autorun.htm 480@480
 ICON=AUTOPLAY.EXE,0

This specifies to run the autoplay executable (deployable from this package)
to display 'autorun.htm' in the root directory with area for a 480x480
image/page. The 'command line' arguments are parsed by
<AutoplaySessionManager> and passed to <Autoplay> before it is shown. The
separator between the width and height is not important as long as it is not
whitespace.

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

> It is not necessary to install anything on the host machine (unless you
have
> used external components that required installation). We gave out a stack
of
> Dolphin trial CDs* at a conference some years ago that had an autorun
> executable
> on them written in Dolphin itself. DPro includes the fundamentals of this
as
> an autorun sample. I've pasted the package comment below.
>
> All of the DLLs can exist in the same directory as the deployed
executable.
> If you deploy as a ToGo executable (frankly there isn't much reason not to
> do so) then you won't even need the VM DLL - just place the C runtime
> library DLLs (MSVCRT.DLL and MSVCP60.DLL) in the root of the CD where the
> autorun exe lives. In most cases you'll get away without those because
they
> are used by so many other programs that they are almost certainly on the
> machine already, but to be sure put them on the CD because they don't take
> much room.
>
> Of course your autorun doesn't need to be a setup menu, you could launch
> directly into the executable. To do that all you'd need would be to deploy
> your application in ToGo mode, place it and the CRT DLLs on the CD, and
then
> write an autorun.inf to lauch it.
>
> Regards
>
> Blair
>
Thanks very much - that all looks very clear and simple. This information,
with the urgings of Bill and Chris above, has overcome my congenital
stinginess and persuaded me that it is now time to upgrade to Dolphin Pro. I
hope there will be no problems in transferring my program from DVE to DPro -
I presume I just file it all out as a package and install that in the DPro
image. Then, when I'm feeling more adventurous, I can explore the mysteries
of refactoring and try to tidy up the structure of what I have done.

Thanks

Peter

Peter,

> Thanks very much - that all looks very clear and simple. This information,
> with the urgings of Bill and Chris above, has overcome my congenital
> stinginess and persuaded me that it is now time to upgrade to Dolphin Pro.

Andy, Chris and I will be expecting our usual 16 oz royalty for this latest
sale :)


> I
> hope there will be no problems in transferring my program from DVE to
DPro -
> I presume I just file it all out as a package and install that in the DPro
> image.

That's pretty much it - save the packages in DVE, copy them underneath your
DPRO image directory, and load them into it.  <shamelessPlug>As you get
hooked on Dolphin and end up with a small invasion of your own packages, you
might want to consider using Migrate</shamelessPlug>.


> Then, when I'm feeling more adventurous, I can explore the mysteries
> of refactoring and try to tidy up the structure of what I have done.

The integration of the RB is excellent.  A search of the archives will
reveal that I'm not a fan of its reformatting of comments (that has _not_
changed), but there are refactorings (e.g. pull up, push down) that do not
rewrite code and that I use quite often.

Have a good one,

Bill

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

> Thanks very much - that all looks very clear and simple. This information,
> with the urgings of Bill and Chris above, has overcome my congenital
> stinginess and persuaded me that it is now time to upgrade to Dolphin Pro.
I
> hope there will be no problems in transferring my program from DVE to
DPro -
> I presume I just file it all out as a package and install that in the DPro
> image. Then, when I'm feeling more adventurous, I can explore the
mysteries
> of refactoring and try to tidy up the structure of what I have done.

I bought DVE and straight away went and upgraded Pro. Look at it this way,
you get an upgrade to Dolphin 6 at the end of year for only the difference
in price..

Bill,
 
> Andy, Chris and I will be expecting our usual 16 oz royalty for this
> latest sale :)

Certainly but, presumably, the missing 4oz will be accounted for as a
tax applied by my good self to all reward beverages (over here pints
are 20oz you see).

Best regards,
 
Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> Certainly but, presumably, the missing 4oz will be accounted for as a
> tax applied by my good self to all reward beverages (over here pints
> are 20oz you see).

I forgot about that.  IIRC, Lockheed-Martin lost $100,000,000 or so over
a radix confusion, so four oz of ale isn't too bad, and it will be for a
good cause.  However, there might be some use for a new method in Locale :)

Have a good one,

Bill

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

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

> Of course your autorun doesn't need to be a setup menu, you could launch
> directly into the executable. To do that all you'd need would be to deploy
> your application in ToGo mode, place it and the CRT DLLs on the CD, and
then
> write an autorun.inf to lauch it.
>
> Regards
>
> Blair

Just to continue the saga, I have now obtained DPro and done some testing,
and things were almost as easy as they seemed from the description.

a. Transferring my application as a package from DVE to DPro was a doddle.

b. Deploying the application as a To Go executable was almost a doddle. The
main view for my program is an adapted version of the Class Browser shell,
and apparently I had not taken out all references to the resources that the
CB uses. These had presumably been stripped early on in the process, and the
system halted complaining about missing resources. I got it to work just for
testing purposes by telling Lagoon not to strip redundant resources and
methods. (I shall of course tidy up the shell before I deploy it for real.)
Apart from this deployment was easy, and took under a minute.

c. The deployed .exe was just copied to a CD-R, not bothering with autorun,
and it worked on every machine I tried it on, including two antiques more
than seven years old running Windows 95, so there should not be any problems
in distributing to potential users.

Just one query about a minor problem I have found. Two of my sub-views
present list views in iconic form, and I have overridden the icon method to
make the displayed icon convey information about the state of the object.
However, the icons visible when running under the development system are all
replaced with a question icon in the deployed version - presumably the
others have been stripped. If possible I would like to restore them for my
program to use. Can anyone tell me: (a) is this physically possible? (b)
would it infringe Dolphin copyright?

Thanks

Peter

Peter,

> Just one query about a minor problem I have found. Two of my sub-views
> present list views in iconic form, and I have overridden the icon method
to
> make the displayed icon convey information about the state of the object.
> However, the icons visible when running under the development system are
all
> replaced with a question icon in the deployed version - presumably the
> others have been stripped. If possible I would like to restore them for my
> program to use. Can anyone tell me: (a) is this physically possible? (b)
> would it infringe Dolphin copyright?

It might be as simple as including the development resources DLL with your
exe, and I _think_ OA allows that.  Your use of the CHB is more distressing;
if I understand you correctly, you should check w/ OA about licensing.

Have a good one,

Bill

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

Peter Kenny wrote:

> However, the icons visible when running under the development
> system are all replaced with a question icon in the deployed version -
> presumably the others have been stripped. If possible I would like to
> restore them for my program to use. Can anyone tell me: (a) is this
> physically possible?

The icons are stored externally to the image, typically in the developer
resource DLL that Bill has mentioned.  If you don't want to include that DLL as
part of your distribution (I'm fairly sure that OA have said that it's OK to
do so), then you can add icons to the .exe directly, although it's a bit messy.

You need to find a resource editor (I use MSVC++ myself, others have
recommended reswhacker (sp?)).  You then make a copy of the stub .exe file in
the <dolphin> directory.  For most purposes, GUIToGo.exe is the right stub to
start from.  You then edit the resources in your copy to add whatever icons you
need, and perhaps also to change the !APPLICATION.ICO (which is used as the
application's icon).  You can then use that stub instead of the standard one
when you are deploying, it's controlled by the #stubFilePath property of the
#imageStripper of the Package that you deploy from (or it can be set from
Lagoon).


> (b) would it infringe Dolphin copyright?

This stuff is undoubtedly /controlled/ by OA copyright, but -- as I said
above -- I'm fairly sure that OA have said it's OK to redistribute their icons
as part of a deployed .exe.

    -- chris

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

>
> The icons are stored externally to the image, typically in the developer
> resource DLL that Bill has mentioned.  If you don't want to include that
DLL as
> part of your distribution (I'm fairly sure that OA have said that it's OK
to
> do so), then you can add icons to the .exe directly, although it's a bit
messy.
>
Thanks Chris and Bill. The resource file DolphinDR005.dll is what is needed;
as long as that is in the same directory as the executable, the icons are
available at run time. The resource file is listed as redistributable in the
documentation, so that should be OK. It seems a bit disproportionate to have
a 1.4MB .dll as resource for a 0.85MB .exe, but if I am distributing it on a
CD there is no problem - it might matter if I later have it available as a
download!

I hope Bill's concerns about the CHB view are misplaced. What happened is
that I saw a close analogy between the way my application works, with a tree
structure of time series, each series having several alternative seasonal
adjustment models and each model having a number of ways of presenting
diagnostic data about the adjustment, and the working of classes, methods
and source code in the CHB. I decided to follow the design of the CHB view
in my view. It was a moot point whether it would be easier to build up my
own view from scratch in an empty view composer, following the order of the
sub-views in the CHB view, or to start from the CHB view and adapt it to my
needs, discarding some bits and changing others. I decided on the latter,
discarding almost nothing, because I am not yet certain what extra
facilities I shall need beyond those already there. For instance, my view
still has the CHB toolbar, all greyed out and connected to nothing, because
one thing I shall ask people who try the prototype is what they would like
to have on a toolbar rather than from menus. Similarly I still have the
categories/protocols/variables panes, also doing nothing, because they will
have a use in later versions.
My reading of the View Composer documentation is that we are explicitly
encouraged to use existing views as the starting point for adaptation in
this way; the  CHB view that I took as my starting point is in the VC
Toolbox. If there are problems, I shall go to the other route and build up
my view from scratch.

One curiosity of what I have done now is that there are a number of minor,
mostly cosmetic, differences between the view as it appears in the
development image and the view generated by the .exe. There are things like
a frame round the graph pane which disappears in the .exe, the column
headers of a list view are smaller in height and with a recessed appearance,
the icons seem to have a dark background  and so on - nothing important
really, but puzzling. It does mean, however, that I shall have to look at
the .exe version before I decide that I have the view appearance right.

It occurs to me that I am generating quite a lot of questions for this
group, all fairly elementary and all being answered by the same faithful
few. If you think I am overdoing it, tell me to shut up and go away.

Peter

Peter,

> One curiosity of what I have done now is that there are a number of
> minor, mostly cosmetic, differences between the view as it appears in
> the development image and the view generated by the .exe. There are
> things like a frame round the graph pane which disappears in the
> .exe, the column headers of a list view are smaller in height and
> with a recessed appearance, the icons seem to have a dark background
> and so on - nothing important really, but puzzling. It does mean,
> however, that I shall have to look at the .exe version before I
> decide that I have the view appearance right.

If this is on XP then you will need a manifest file to get the XP look and
feel.  If you go to the dolphin.exe folder you will find a file called
Dolphin.exe.manifest.  Copying that to the folder where your executable
resides and renaming it as yourfilename.exe.manifest should do the job.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian, Peter,

> > One curiosity of what I have done now is that there are a number of
> > minor, mostly cosmetic, differences between the view as it appears in
> > the development image and the view generated by the .exe.
> > [...]
> If this is on XP then you will need a manifest file to get the XP look and
> feel.  If you go to the dolphin.exe folder you will find a file called
> Dolphin.exe.manifest.  Copying that to the folder where your executable
> resides and renaming it as yourfilename.exe.manifest should do the job.

Incidentally, you can also include the manifest file in the resources embedded
in
the ToGo stub, in much the same way as you can embed icons, etc, as resources.
That saves you having to remember / include / distribute the manifest file
separately.

There are sketchy instructions for doing it on the Wiki.  It'd post a more
detailed "howto" using MSVC++, except that I have completely forgotten what I
did...  (it wasn't hard, though)

    -- chris

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

> If this is on XP then you will need a manifest file to get the XP look and
> feel.  If you go to the dolphin.exe folder you will find a file called
> Dolphin.exe.manifest.  Copying that to the folder where your executable
> resides and renaming it as yourfilename.exe.manifest should do the job.
>
Thanks Ian. I am using XP, and that does the trick. I had not realised that
there is a distinctive XP 'look', since the differences are fairly subtle.
It does mean that I should check my program on a non-XP machine to see how
it looks there, so there is still a use for my old Win95 machines!

Peter

Peter,
 
> Thanks Chris and Bill. The resource file DolphinDR005.dll is what is
> needed; as long as that is in the same directory as the executable,
> the icons are available at run time. The resource file is listed as
> redistributable in the documentation, so that should be OK. It seems
> a bit disproportionate to have a 1.4MB .dll as resource for a 0.85MB
> .exe, but if I am distributing it on a CD there is no problem - it
> might matter if I later have it available as a download!

An alternative is to just copy the ICO files that you want to use into
the directory where your EXE is installed. The system should then find
these automatically and you won't need to distribute that huge DLL.

Erm... it seems to me that you may be infringing the license. The
REDIST.TXT file states that the ClassBrowserShell is one of the
development system components and so should not be redistributed as
part of your application.

 From what you say above, it seems that you are only re-using the view
resource and not the associated Smalltalk code. Strictly speaking this
is still not allowed by the license but why not drop us a line to
explain what it is that you are doing and we'll probably be able to
give you permission to "bend the rules".

Best regards,


Andy Bower
Dolphin Support
www.object-arts.com

Andy, Peter,

> An alternative is to just copy the ICO files that you want to use into
> the directory where your EXE is installed. The system should then find
> these automatically and you won't need to distribute that huge DLL.

Slick - I didn't know about that possibility..


> Erm... it seems to me that you may be infringing the license. The
> REDIST.TXT file states that the ClassBrowserShell is one of the
> development system components and so should not be redistributed as
> part of your application.

That's what I thought.


> From what you say above, it seems that you are only re-using the view
> resource and not the associated Smalltalk code. Strictly speaking this
> is still not allowed by the license but why not drop us a line to
> explain what it is that you are doing and we'll probably be able to
> give you permission to "bend the rules".

That's what I have come to expect from Object Arts.  Well done.

Have a good one,

Bill

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