How create a Trial Version?
Jörg Heßler
or .dll's to reach this?
Thanks
Jörg
Gregory Adam
No tools nor dlls I know of
Why don't you put in some mechanism that your exe checks.
eg : have your app distributed with a .ini file. In there is (encoded of
course)the NAME of the company you show on all reports and the _vfp.caption,
the serial number, add-ons bought, ...
If no valid serial number quit
if option 1 available show option 1 on the menu
...
you could do something like that and put in a date limit, a table number of
records limit, ...
There's only a few places where you have to put the checks
"Jörg Heßler" <JoergH...@t-online.de> wrote in message
news:8p7j59$v89$10$1...@news.t-online.com...
Grady
What I do is put a password and id in front and force trial users to enter
with "GUEST" as the password and Id. Then I limit access to what I want the
guests to be able to see or do by referencing the password and Id.
Something along this lines
IF PWENTRY = "GUEST" AND IDENTRY = "GUEST"
WAIT WINDOW "Some message here says guests may not update records or
something" nowait
RETURN
ELSE
DO FORM FORMNAME
ENDIF
PS I haven't tested the above code. I just banged it into the response. So
be sure to write and test your own.
"Jörg Heßler" <JoergH...@t-online.de> wrote in message
news:8p7j59$v89$10$1...@news.t-online.com...
Carlos Alejandro Pérez
by mechanisms like password-based ones. If your system is worthy, they will
try to break such mechanism, once discovered, you're out of business.
Perhaps a limited number of records could be acceptable. Perhaps your trial
code will work only in monouser mode, so you can reindex the tables freely.
If so, you can INDEX ON... TAG .. FOR RECNO("mytable")<1000, and when in
use, set exclusive always to avoid the table sharing and the possibility of
change that. Of course, you should reindex the tables every time you enter
to the app. Or even better, DELETE FOR RECNO()>1000 for every table and PACK
or something like that. Disable the ESC key, etc. etc.
Another good strategy is number-of-executions, or time expiration period.
You could mantain the date in a DLL , or INI dummy file in the system
directory, the system knows it and checks for the file date creation to
perform expiration calculation. If the machine clock is manipulated they
could be done, but it is not a good idea. Your system could write a
encrypted log file in certain windows directory in order to accumulate the
number of executions, regardless the machine clock gambling.
You could consider the use of a dongle. I have a Hardlock eval kit, and I
found the encryption capability quite interesting. In addition, you can
record in its tiny rewritable memory a date, or accumulate
number-of-executions. Of course, the system will be plagued of callings to
the verification procedure, but there's not other way. Another possibility
is to generate a standard exe, fully functional, and use the dongle
"software wrapper" to scramble the exe itself ,and add some time expiration
capability.
Last but no least, remember that no matter what you do, if they consider
your system has enough potential, they will break the dongle, or any
mechanism I mentioned above.
Regards
Carlos
MAppell917
app does.
Mike
William Steinford
some for sale that basically will allow Full access for a given period
of time (like 30 days) then disable it altogether (it was at
www.zaccatalog.com, but that's closed now... try
www.componentsource.com).
However, we've found it useful to simply limit what a "Demo" user can
do. The mechanism I use is to have a routine called Rights(
pcFunctionality, Param1, Param2 ... ) and anywhere that I want to
limit under different circumstances, I just call Rights().. ie:
* In code called by a menu choice "Hardware Setup":
if not Rights('Hardware Setup')
wait window "You don't have the right to change the hardware setup"
RETURN
endif
* Now do the real stuff!!
This design is much more flexible than a third party tool, and simple
to implement (a tool wouldn't make it easier). You have to figure a
way to store and change the users current access level (we use a
weakly encrypted text file with ambiguous information in it).
The Rights() function looks like this (it can reference whatever
global status variables you want; Here I use LoginLevel to represent
the access level of the user, 0=demo, 4=administrator; pvParam1 and
pvParam2 are additional parameters that can be whatever is relevant to
any particular functionality):
FUNCTION Rights
LPARAMETERS pcFunc, pvParam1, pvParam2
LOCAL RetVal, lcFunc
RetVal = .T.
lcFunc = upper(pcFunc)
do case
case lcFunc="HARDWARE SETUP"
If LoginLevel < 4 && Not an Administrator
RetVal = .F.
endif
case lcFunc="SAVE FILE"
if LoginLevel = 0 && Demo Mode
RetVal = .F. && not allowed to save
endif
case lcFunc="CHANGE NUMBER OF TEAMS"
if LoginLevel=0 and pvParam1>MAX_TEAMS_FOR_DEMO
* Demo mode can't do full functionality
RetVal = .F.
endif
endcase
RETURN RetVal
Unknown
posted already is that if your app is sufficiently sophisticated, be
careful about distributing a full working demo. Novice users and users
who think they know more than they do will figure your app does not
work properly instead of they're not using it properly. We've noticed
this especially if there is technical information being used, eg.
mortgage calculations.
On Thu, 7 Sep 2000 10:27:10 +0200, "Jörg Heßler"
<JoergH...@t-online.de> wrote:
>I will distribute my foxpro-applications as a trial version. Who knows tools
>or .dll's to reach this?
--
John
John...@NoteSSmith.com
(Spam avoidance: Actual address has one S.)