Click above to get retro games delivered to your door ever month!

                             Sample Source
------------------------------------------------------------------------------

The file SAMPLE.PRG contains a typical application that includes almost
every basic feature of the library.  This file is well documented.
The examples in this section break apart the different modes of
operation, from copy protection to execution-count limiting.

To Copy Protect

There are five simple functions that you need to be familiar with
in order to copy protect you application.  First, PP_UCODE() will
be used to "hide" the functions PP_COPYWRITE(), PP_CENUM(),
PP_COPYCHK(), and PP_KILLPROT().  PP_UCODE(), as we will
now call the "user-code function," is added most commonly with
the set key to statement.  That way, when a user presses a function
key (let's use F5), a pop up will then display a number and ask for
a number.  The number displayed is the code entry number.  This
number is explained under PP_CENUM() in the function reference.
The number the user has to type in is one of the unlock codes.
The number he (the user) types in is passed to PP_UCODE().  This
function will then decode the number, and return a number between
zero and eighteen (0-18).  This number corresponds to the user
code to which you assign functions.  Usually a DO CASE structure
is employed to determine which function to run.  If the function
PP_UCODE() returns a zero (0), the code entered was invalid.

Once the structure is set up, you can place the other functions
PP_COPYWRITE() and optionally PP_KILLPROT() in the DO
CASE structure.  These functions create the copy protection file
and erase the protection file, respectively.  Refer to the file
SAMPLE.PRG function UCODE() for an example of this.

Monthly Unlock (payments)

Creating an application that must be unlocked every month on a
certain day is simple.  This would be used if, for example, your
application is leased.  The same basic method described in  To
Copy Protect dealing with PP_UCODE() is used.  If copy
protection is used, the method described in that section will be
implemented along with at least two other functions for the
payments.  PP_NPDATE() will return the date for the given day of
the month that you would like to expire.  If that day is on a
weekend, it will return the next Monday.  PP_NEXPTYPE() is
used in conjunction with this function to advance the next expira-
tion date.  You would pass it a "P" for payments and
PP_NPDATE() as shown in the file SAMPLE.PRG.  Last, the
application leaves your computer serialized and ready to expire on
the day of next month that you setup.  You have total control on
how the system is setup!

Application with Modules

If your application is sold in modules, and the user can purchase
only what he needs, you could actually ship him the entire
package.  How you would set it up, assuming that every module
has a separate EXE file, is assign a different control file to each
module.  This would be done even if the program is not packaged
as separate EXE files.  In PROPLUS.EXE, you would have a client
record for every client and every module in that package.  This
might be a bit cumbersome at first, but look at the power you have.
You could, at will, enable a module to work as a demo remotely.
This would be great if your user calls you up and says he is now
interested in another one of your modules.  You could, over the
phone, enable the module he wants, and not have to worry about
it stopping on a certain day or after so many executions.

This is how it is set up.  First, the main EXE file (or main menu
routine), will have its normal control file.  When the user presses
the menu function that calls a module, change the value of
PP_CFILE to reflect the new module.  You can then see if it is
unlocked.  If it is, run the program, else print a message or
whatever else you want.  BE SURE to change PP_CFILE back to
its original value when complete with that module.  When you
change the status of a module for a client, use PROPLUS.EXE to
keep track of when it was installed, when it will expire, etc.  At the
touch of a button, you will know which of your clients is using
which modules.

The addition of protection or demo modes for the main program
and its modules is all controlled through the PP_UCODE()
function.  Refer to this function for coding examples.  You could
even "nest" the user-code values to effectively achieve more than
18 hidden user-codes.