SetupBuilder Magic Requested

[NewsArchive]

I have a complex SetupBuilder install that I want to trick up a bit.

Here's the situation:

From one SB build the potential customer can install the program but cannot
enter more than 30 names into the database until they contact me and I give
them their Registration Number (See Attachment).

This works well except that after a year I want to prevent them downloading
the Free Trial and updating their program without signing up for year
maintenance subscription.

Embedding a date in the security file doesn't really help because one
customer may have many dates (one for each program he installs). But has
only one renewal date no matter the number of installs.

One approach I considered was to have the Security file deleted each time a
new version is installed requiring re-registration. This would be a PITA
for me and the customer but would work.

So I was hoping to have one SB script that would delete or not delete the
security file depending where they downloaded from (my demo page or a
password restricted Customers Only page).

Anyway I hope maybe some SB magic could be applied. ;-)

Any ideas ?

--
Lynn Howard
Linked Software
www.linkedsoftware.com

[NewsArchive]

Lynn,

> So I was hoping to have one SB script that would delete or not delete
> the security file depending where they downloaded from (my demo page
> or a password restricted Customers Only page).

Does the installer "know" where it came from (e.g. do you have different
setup.exe files on your demo page and your password restricted Customers
Only page)? In other words, what should "trigger" the delete security file
action?

Friedrich

[NewsArchive]

Thanks for your reply.

Let me answer with a question.

Without making two separate installs with only one line difference (to
delete the Registration File) is there another way?

Lynn

[NewsArchive]

Lynn,

You can certainly use a compiler variable to create the two different setup
exes from the same setup builder project.
You use the command line to supply the compiler variable value and build
both versions of the installer from a batch file or script.

JAT,
Rick

[NewsArchive]

> Thanks for your reply.
>
> Let me answer with a question.
>
> Without making two separate installs with only one line difference (to
> delete the Registration File) is there another way?

How would you do it without SetupBuilder? Let us assume, you check your
hard drive and find your setup.exe which you downloaded from the web some
weeks ago. Can YOU find out whether it's from your demo page or a password
restricted Customers Only page? In other words, is there a specific
"footprint" that tells us about the original location? If this is the case
then we can "translate" this method to the setup deployment logic. But as I
understand it you only have one setup.exe.

If you have the same trial setup.exe (binary identical files) then there is
no way to retrieve the source location of the downloaded files. Only if you
"hard-code" the information into the executable.

But what about using a specific "security code" which the user has to enter
before continuing with the install? For example, you display this code on
your password restricted Customers Only page. If the user does NOT enter it
or enters an incorrect (or outdated) key in the setup then chances are that
it's from your demo page. You can then delete the security file, etc. You
can change the security code from time to time (e.g. once every 6 months or
when you make a new version available) to restrict the use of your trials.
You can even let the installer download a specific file from your web site
that stores the security code (note: Internet access is required when the
user installs). You can then change the security code on a regular basis
(only update the security file on your web server) and restrict the
reinstall of the downloaded trial versions.

Friedrich

[NewsArchive]

Thanks to you all. The fog is lifting!

The hopeful goal is to have only one install program and I believe it can be
done using Friedrich's suggestion.

Have an option window:

- Free Trial
- Registered Customer

If Free Trial is selected then after due warning the SB code deletes the
Security File.

Otherwise if Registered Customer is selected the password from the Customers
Only page will not delete the Security File.

So can this be done in SB code? I'll bet it can. <G>

Thanks!

Lynn

[NewsArchive]

Yup.

Off the top of my head, make a custom dialog with your two option buttons.

In the script something like this (psuedo-code):

IF %CHOICE% = $Trial
Remove(Registry.tps)
END

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

Thanks Russ,

I knew SB could do it. It can do anything but print money and in its own
way it does that too.

Lynn

[NewsArchive]

Lynn,

>
> So can this be done in SB code? I'll bet it can. <G>
>

If you are interested, I can develop a small demo project for you.

Friedrich

[NewsArchive]

I'm so glad you asked. Spent the morning reviewing all your examples. I
forget so easily these days.

Here's my current thinking: Comments?)

Thanks a million!

Early in my existing install program.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ask if this is a Free Trial or Update for Registered customer
IF Free Trial selected
Dialog warning Registered customer not to do this
Let Registered Customer opt out
IF Program running (Program Files, Linked Software)
Shut program down with message (Program shouldn't even exist for Free
Trial but might)
Delete Security file (shouldn't exist but might) (CISDL, Docs, All
Users, Linked Software, Common)
IF file doesn't exist or successfully deleted
Continue with rest of main install
ELSE
Exit
END
END
ELSIF Registered Customer
Dialog to contact Linked Software for Password
Enter Password
IF Password Correct
Continue with main install
ELSE
Exit
END
END
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Summary: Main install doesn't create or over-write Security file so if the
password is correct it won't be deleted and Security File is left intact.

Lynn Howard