Two SetupBuilder Suggestions

[NewsArchive]

Hi Friedrich,

My latest SB project has inspired two suggestions:

1. The help topic for the Readme dialog might be improved. I gather from
experimentation that using a readme file requires that I include that file as a
Support File, correct? Perhaps the help topic could explain this.

2. I find it painful to create new installers from scratch because I have to
duplicate many settings and entries in order to maintain consistency. Often
this requires opening a second instance of SB and copying from it to the new
project. It would be great to be able to define a "template" with all the
preferences settings common to all my installers. Ideally, a change to the
template would be reflected in all associated SB projects, much like a change
to a Clarion template is reflected in compiled .apps. Perhaps something as
simple as an entry for a "MyTemplate.ini" file name in the SB project
definition and some mechanism to allow references to the .ini file values to be
placed in SB entry fields [Template.TopBitmap] or [Template.TimeStampURL]. Does
this make sense?

Thanks again for the great product and support!

Greg Fasolt

[NewsArchive]

Hi Greg,

> My latest SB project has inspired two suggestions:
>
> 1. The help topic for the Readme dialog might be improved. I gather from
> experimentation that using a readme file requires that I include that file
> as a Support File, correct? Perhaps the help topic could explain this.

No, this is not correct :) You don't have to include the readme file as a
Support File!

> 2. I find it painful to create new installers from scratch because I have
> to duplicate many settings and entries in order to maintain consistency.
> Often this requires opening a second instance of SB and copying from it
> to the new project. It would be great to be able to define a "template"
> with all the preferences settings common to all my installers. Ideally,
> a change to the template would be reflected in all associated SB projects,
> much like a change to a Clarion template is reflected in compiled .apps.
> Perhaps something as simple as an entry for a "MyTemplate.ini" file name
> in the SB project definition and some mechanism to allow references to
> the .ini file values to be placed in SB entry fields [Template.TopBitmap]
> or [Template.TimeStampURL]. Does this make sense?

Well, you can already do this. If you consistently use the same default
settings in your installation routines, you can create installation
templates
that can be used as starting points for your installs.

Templates are pre-defined starting points for new projects. You can use
templates to:

- Provide a standard UI with company logo, layouts, and any standardized
reusable configuration information for all your projects

- Provide functional templates for specific project types such as Web Update
deployments

- Provide base components for a product line

Example: Suppose that all the installations you create have the same system
configuration requirements and the same dialogs. You can create a new
template that has those changes preconfigured. To do this, you would create
a new installation, make the necessary changes to the System Requirements
and Dialogs pages, and then save the installation in a specific location.
Thereafter, every time you create a new installation, the template you saved
is available to build new installations.

Then make use of compiler variables, include scripts, and the Releases
technology and you have a *very* flexible system ;-)

What do you think?

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6.7
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Greg Fasolt

>Hi Greg,
>
>> My latest SB project has inspired two suggestions:
>>
>> 1. The help topic for the Readme dialog might be improved. I gather from
>> experimentation that using a readme file requires that I include that file
>> as a Support File, correct? Perhaps the help topic could explain this.
>
>No, this is not correct :) You don't have to include the readme file as a
>Support File!

Thanks -- perhaps this shoulr be mentioned in the docs?
>
>> 2. I find it painful to create new installers from scratch because I have
>> to duplicate many settings and entries in order to maintain consistency.
>> Often this requires opening a second instance of SB and copying from it
>> to the new project. It would be great to be able to define a "template"
>> with all the preferences settings common to all my installers. Ideally,
>> a change to the template would be reflected in all associated SB projects,
>> much like a change to a Clarion template is reflected in compiled .apps.
>> Perhaps something as simple as an entry for a "MyTemplate.ini" file name
>> in the SB project definition and some mechanism to allow references to
>> the .ini file values to be placed in SB entry fields [Template.TopBitmap]
>> or [Template.TimeStampURL]. Does this make sense?
>
>Well, you can already do this. If you consistently use the same default
>settings in your installation routines, you can create installation
>templates
>that can be used as starting points for your installs.

I do this, but this is only a starting point and lacks the ability to maintain
changes consistently. It would be so nice to change a dialog graphic or code
signing password, add or remove a base component, change the license file, etc.
in one place and automatically update all "associated" projects.


>
>Templates are pre-defined starting points for new projects. You can use
>templates to:
>
>- Provide a standard UI with company logo, layouts, and any standardized
>reusable configuration information for all your projects
>
>- Provide functional templates for specific project types such as Web Update
>deployments
>
>- Provide base components for a product line
>
>Example: Suppose that all the installations you create have the same system
>configuration requirements and the same dialogs. You can create a new
>template that has those changes preconfigured. To do this, you would create
>a new installation, make the necessary changes to the System Requirements
>and Dialogs pages, and then save the installation in a specific location.
>Thereafter, every time you create a new installation, the template you saved
>is available to build new installations.

This is a very good point.
>
>Then make use of compiler variables, include scripts, and the Releases
>technology and you have a *very* flexible system ;-)
>
>What do you think?
>
>--
>Friedrich Linder
>Lindersoft
>www.lindersoft.com
>+1.954.252.3910
>
>"point. click. ship" - that's SetupBuilder 6.7
>Create Windows Vista ready installations in minutes
>
>-- Official Comodo Code Signing and SSL Certificate Partner
>
>
>