Compiling
Why can't I compile my 4D database?
If you are unable to compile your 4D database, there are a number of things
you should check:
- Are you using a matching compiler for the version of standalone or server
that you used? A 4D v6 or later database should be compiled with the latest
4D v6 or later compiler.
- Have you dealt with the constraints on applications that can be compiled?
These constraints are discussed in the compiler manual. The most common
problems are syntax errors (commands, or parameters to commands, that
are not correct) and type declaration errors (trying to re-type a variable,
for example).
- If your application is converted from an earlier version of 4D, you
should check that you don't have one of the more common problems that
can occur in this situation. (See FAQ on
Plug-ins)
What compiler options should I use?
There are several different categories of compiler options. The effects
of all of these options are described in the Compiler manual. The following
are the most important comments about the best values for these options:
- "Create Executable Application" allows you to create a standalone,
double-clickable application that does not need any version of 4th Dimension
to run. Note that you must buy a 4D Engine license in order to use this
option.
- "Create Error File", if turned on, will cause 4D to create
a file containing all of the errors found during the compile. When you
turn this option on, 4D Compiler will ask you for a name and location
for this file. You should save the file in the same location as your structure
file, and with the same name (with a .ERR extension). When you next open
that structure file in Design mode, there will be a new pair of options
at the bottom of the Use menu. These options will let you see each of
the errors generated and its location (by opening the method in which
the error occurred with a message at the top of the window), and to turn
off this feature, respectively.
- "Symbol Table", if turned on, causes the compiler to write
a text file which tells you about the names and types of all the variables
in your database.
- "Range Checking", if turned on, causes the running 4D compiled
application to check the value contained in any variable before it performs
an operation on that variable, to determine whether that variable has
a valid value. If the value is valid, the operation is performed. If the
value is invalid, the compiled application will generate a useful error
message. Without this option, 4D will try to use any invalid value in
a variable without checking it first, which can cause unpredictable results
or crash 4D. On the other hand, turning this option on makes a compiled
database structure larger and slower than it would otherwise be. Generally,
you will compile with this option turned on for your application at first
to test it. If you use the database for some time without getting any
range-checking errors, you would then turn it off to speed up the database.
- The "PowerPC On" option should work for versions of the PowerPC
processor. In particular, it should work for the PowerPC 750 processor
used in Apple's G3 Macs and newer.
- "Warnings", if turned on, will cause Compiler to alert you
to potential problems in your database as it compiles. These problems
will not prevent compilation, and may not actually be problems at all.
However, the conditions the compiler detects under this option are frequently
indications of problems. You should usually compile with this option set
to Basic. If you understand the messages it gives, you should use the
Advanced option.
- If you wish to compile for Windows, you should turn on the "Pentium
optimised" option unless you expect to be using mostly non-Pentium
computers. The Pentium-optimised compiled version will still run on non-Pentiums
PCs.
- The "Script Manager" option, if turned on, will let 4D support
Apple's advanced text engine to display non-Roman characters (such as
Japanese, Korean, Russian or Chinese characters). This option only affects
Macintosh computers, and you should turn this off unless you expect to
be working with such characters.
- The "optimisation" should usually be set to Advanced. However,
this will slow down compilations. If you are doing frequent compiles during
testing and these compiles are taking considerable time, you should turn
this option off, and turn it back on when you want to compile your final
version.
- If you turn on the "Typing File" option, 4D Compiler will
generate a text file containing the typing information it generated for
the variables in your database. You can then copy the text from this file
into a method in your database to make these typing decisions more explicit.
Note that you are usually better off explicitly typing all of your variables
yourself, rather than allowing 4D Compiler to try to make variable typing
decisions for you. You should read the discussion of this subject in the
Compiler manual.
- The "Compilation Path" option lets you tell 4D Compiler what
typing information you have included in your code already. If you explicitly
type all variables in your database, you can choose the All variables
have been typed option, which makes compilation considerably faster. If
you didn't type your local variables, the second, "Process and Interprocess
have been typed" option is still faster than the first, default option.
Note that 4D recommends that you should usually explicitly type all variables
in your database.
- The "Default Type" options let compiler type various types
of objects for you. 4D recommends that you should explicitly type these
variables yourself. Objects on forms should be typed in the first process
method in which they are used, or in some similar logical place.
Can I merge with Engine for another platform?
No. While you can compile for either platform on either platform to run
that code with runtime, standalone or server, you must compile and merge
with 4D Engine for Windows on a Windows computer, and with 4D Engine for
Mac OS on a Macintosh.
Should I always declare local variables in a compiled
structure?
Yes, always type any variable (local or otherwise) regardless of your choice
in the "Initialize Local Variables" option found in the Compiler
Project dialog box. 4D Compiler types variables based on inference. In other
words, it tries to figure out how you are using the variable. Under some
conditions, the compiler may not understand how you want the variable typed.
Be careful not to confuse "Initialize" with "Declare".
initialising is the process of assigning a value; declaring is the process
of typing. When compiling, you (as the database author) can type the variables,
or you can let Compiler attempt to declare variables. However, good programming
practice is to declare and initialise all variables explicitly.
Subtotal in Compiled Mode
When I try to subtotal variables on a break report, in interpreted mode,
I receive the correct values. In compiled mode, I receive zero as my subtotal.
What's wrong?
You should not rely on the Subtotal function alone for reports. In addition,
you should use the BREAK LEVEL and ACCUMULATE commands.
What is the Universal 4DX folder?
In version 6.0.x of 4D, if you wanted your database to load and use a plug-in
(such as 4D_Pack, 4D Write, etc.), the plug-in was required to be placed
inside of a (Mac or Win) 4DX folder that resided inside the same directory
as your structure. Version 6.5 of 4D introduced the new concept of a "Universal
4DX" folder. A "Universal 4DX" folder is a (Mac or Win) 4DX
folder that resides inside the 4D folder which is inside your platform's
active "system folder" (WinNT folder, Windows folder, or on the
Mac the System Folder:Preferences folder). Should you do an install from
the version 6.5.x Product CD you will, by default, end up with a Universal
4DX folder.
The concept of the "Universal 4DX" folder is as simple as it is
convenient. Now you can place all your plug-ins into it and subsequently
all of your databases will be able to find and load the plug-in(s) that
it requires. In other words, it is no longer necessary to have a 4DX folder
FOR each database WITH each database.
