Thanks
Jörg
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...
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...
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
Mike
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
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.)