Thank you for your post.
One trial solution I used (many years ago - not FileMaker) was to create a field in a file that was always hidden. When the customer launched the file, it would look in the field, and if the value was blank, then today's date was entered to start the 30-day trial. The next time the solution was launched, the initial date was read and compared against today's date. If the difference was greater than 30, then a dialog box displayed stating 30-days had transpired.
This can easily be adapted to FileMaker Pro. You can create a startup script that checks this field, evaluates it, and then decides either to display the dialog box and quit the application, or continue using the solution.
If you need clarification for any of the above steps, please let me know.
I have just implemented such a feature in a soon to be released solution.
The creation of a unique key is the challenge for a number of reasons. It must be fairly secure, otherwise people will crack the key. You have no idea how many teachers did this with my former employer's products. It must easy for your clients to use. It must contain all the information required by your solution to implement the registration features you want.
The expiry date suggestion given by tsgal is great. It does not solve your registration issue.
In my upcoming solution, I implemented the Blowfish cypher in custom functions. When clients will purchase the solution, they will supply me with their business information which will be coded in the encrypted registration text. Upon registration, the solution will record this information. The client will be unable to give the solution to others without the copies displaying the original client's business information on invoices, correspondence, etc. This satisfies our needs. Yours will likely be different.
To make the registration system easy, we will email the registration text in a file. The solution will import the file's content and do the rest of the work.
You can add a ton of features with these custom features and a bit of programming. We include an application code and version as a verifier that the registration file is for the correct product. Additionally, each product has its own encryption sub-keys. You could easily make a registration file that encludes an expiry date, such as those found in subscription based products. Maximum number of users, records, etc., node locking and more is possible. The registration script within each solution determines the extent of the features that can be coded in a registration file.
I will not explain in this forum how to implement Blowfish because it is composed of 10 complex custom functions. Implementing Blowfish from scratch is not for the faint of heart.
The Blowfish custom functions will be released to the general public very soon. The functions exist and are now in use in a production environment. A few external developers are currently reviewing the code and we are awaiting feedback before we release the code. It is not our intent to charge anything for this code.
Let me know if this interests you.
Thank you to both TSGal and David.
Yes, the approach you describe in fact was discussed in another thread here recently. As David mentioned, though, it does not take care of the registration issue. But it can be an effective means of enforcing expiration of a trial.
Thank you for the details involved in your approach. On another product in the past we used a similar (but much less sophisticated) approach whereby the customer's copy ultimately carried personalized information. It served both as a "value added" feature and a piracy deterrent. Your solution is intriguing. However, as it happens, early responses from our testers suggest that we may well be converting our solution into a Web-based hosted subscription type. That of course changes a lot of things but at least affords us more control over registration, activation, renewal, etc.
Thanks again to you both.