Design
Tips for developing trial software with Delphi
|
Dates
|
|
If your code manipulates dates be sure
to test using different date formats (styles, separators). [In Windows
95 for example, date formats can be changed in the Regional Settings
Control Panel.]
If you are using the StrToDate function you should test your app with a
date format having abbreviated or full
month names. The StrToDate function will not see such dates as valid.
This code changes the month format to a two digit format StrToDate can
handle:
{StrToDate must use month as number}
if Pos('MMMM', ShortDateFormat) 0 then
ShortDateFormat:= Copy(ShortDateFormat,1,Pos('MMMM', ShortDateFormat))
+Copy(ShortDateFormat,Pos('MMMM',ShortDateFormat)+3,
Length(ShortDateFormat));
if Pos('MMM', ShortDateFormat) 0 then
ShortDateFormat:= Copy(ShortDateFormat,1,Pos('MMM', ShortDateFormat))
+Copy(ShortDateFormat,Pos('MMM',ShortDateFormat)+2,
Length(ShortDateFormat));
|
Form
'Scaling' and Large/Small Fonts
|
|
It is important to have your forms
looking professional at whatever resolution or font size (i.e. Large
Fonts/Small
Fonts) your users are using.
There are several scaling controls out there (see DSP for example).
However, I have never found them that useful.
To ensure your forms look decent at all resolutions and font sizes you
can take these steps:
- On the form set the AutoScroll
property to False.
- Ensure all forms and controls use a
True Type font such as Tahoma. A non True Type font like the default MS
San Serif can cause problems at different font sizes.
- Set the form's Scaled property to
False.
|
Form
Positioning
|
| The position of your
forms may look OK on your system, but on a machine with a lower
resolution the forms might
default to a position off the screen. To prevent this the form Position
property should be set to something other
than poDesigned. Even better, on application close store the location
of the form (i.e. .Top, .Left properties)
in an Ini file or in the Registry. RxTools has some great controls that
do this automatically. |
Internationalization
|
Decimal Separator
|
|
Some European countries use a comma
for a floating point separator instead of a period. If your program
makes
use of floating point values you should test using both a period and a
comma.
In particular, the StrToFloat function will cause an exception if the
string passed to it has the wrong decimal
separator.
Here is some code which replaces the period in a string with the
default decimal separator stored in the DecimalSeparator
global variable:
{if the string does not have the default separator replace it}
if Pos(DecimalSeparator,strV) = 0 then
strV:= Copy(strV,1,Pos('.',strV)-1)+DecimalSeparator+
Copy(strV,Pos('.',strV)+1,Length(strV)-
Pos(DecimalSeparator,strV));
|
Case Sensitivity
|
| When working with user
text that could contain international characters always use
AnsiUppercase and AnsiLowercase
instead of the Uppercase and Lowercase functions. |
Preventing
Cracks
|
Learn from the Crackers
|
| The best way to learn
how to prevent cracking is to investigate how crackers crack programs. |
Don't Use Unlock Codes
|
| The best way to
prevent cracks is to have two separate builds using conditional
defines. One is your trial, one
is your full commercial version. In the trial put several (maybe two
dozen) different checks to your countdown
timer (no function calls) to annoy any cracker to tears. |
Avoid Message Boxes
|
| Crackers use tools
that can break the execution of your program at any point. If you have
a message box popup telling
the user a reg code was invalid the cracker will easily find out how to
patch the code checking. |
Hide Important Text
|
| Crackers will search
your program for certain text like "Registration Expired". Prevent this
by hiding
the text through encryption or some other means. You can also pepper
decoy text throughout the code. |
30 Day Crack Program
|
There exist several
programs that are able to prevent programs with evaluation time limits
from ever expiring.
Here is a method to deal with at least three such programs: CrackLock,
Daykill 95 and Cracker.
Have the date the app was last accessed, and a counter of the times the
program was used, hidden somewhere in the
Registry. On program start check the date. If it is different than
today's date increment your counter and update
the date. Do another such check in the main form's OnClose event. You
can do more checks in the program as well,
such as whenever the user presses a certain button.
Note that at least some of these crack programs use the
WMQueryEndSession event so running your check here may
not work.
Interestingly enough this method appears to backfire for the cracker
causing the counter to increment twice every
time the program is used rather than merely every different day.
Note that there are now newer "30-day crack" programs that will defeat
the above protections. Flashback
Devil, for example, allows you to assign a date to a trialware program.
Whenever you run this trial app through
Flashback Devil the app will think it's always the same date thus the
trial counter will no longer work. You get
around this by getting the current date from somewhere else, like the
timestamp of the Windows swap file. See the Trialware
Forums for some
source code. |
Other crack prevention link
|
|
|
Programming
|
|
|
Game
Programming
|
|
|
Interface
Design
|
|
|
Q
& A
|
|
|
Icons,
Glyphs and Web Graphics
|
|
|
Developer
Products
|
|
|
General
|
|
|
Press
Release Information
|
|
|
The Delphi
Trialware Developers Page 
