.INI files
To insure your deployed application performs as intended, you can deploy an .INI file of the same name as the .EXE.
Some settings you should consider (see online help in dBASE for details for SET EPOCH, SET CENTURY, SET LDCHECK, etc.) adding as an example below:
[CommandSettings]
EPOCH=1950
LDRIVER=WINDOWS
[OnOffCommandSettings]
CENTURY=ON
LDCHECK=OFF
BELL=OFF
TALK=OFF
[CommandWindow]
Open=1
Maximized=0
Minimized=1
[ComponentTypes]
ComponentTypeNumeric=1
ComponentTypeDate=1
ComponentTypeLogical=0
ComponentTypeMemo=0
ComponentTypeBinary=0
ComponentTypeOLE=0
ComponentTypeNumericForTables=1
ComponentTypeDateForTables=1
ComponentTypeLogicalForTables=0
ComponentTypeMemoForTables=0
ComponentTypeBinaryForTables=0
ComponentTypeOLEForTables=0
[Grid]
DefaultMemoEditor=0
[Toolbars]
Format=0
[ObjectPath]
objPath0=c:\path
objPath9=c:\anotherpath
[IDAPI]
CONFIGFILE01=mycustom.cfg
[UserBDEAliases]
0=dBASEContax
[dBASEContax]
Driver=DBASE
Options=PATH:C:\Users\kkolosky\AppData\Local\dBASE\PLUS\Samples\contax\data
The LDRIVER=WINDOWS setting ensures that no matter what your application's BDE Driver, your source code will be saved as ANSI.
Setting TALK=ON will cause dBASE Plus to constantly echo commands to the command window, and may cause performance degradation. In dBASE Plus, the Runtime Engine automatically assumes talk is OFF
The ComponentTypes settings reduce the likelyhood of datatype mismatches, particularly if you are using the grid component on your forms. You should copy the section shown above from your own DB2K or PLUS.INI, as you may have different settings than those shown above.
Grid was new to dBASE Plus in version 2.21, and is used to set the default columnEditor type for memo fields in a grid. If DefaultMemoEditor is set to zero, the default (columnEditor) is used, if set to one (1), the columnEntryfield is used.
Toolbars: When the Format option is set to "1", the Format Palette is displayed when a form with an editor control is opened. The Format Palette does not display when this is set to “0”.
ObjectPath: This is how DEO is handled. Briefly, when you run an executable built with dBASE, it checks:
It looks in the "home" folder from which the application was launched.
It looks in the .ini file to see if there's a series of search paths specified. It checks all the paths in the list looking for the object file requested by the application.
It looks inside the application's .exe file, the way Visual dBASE did in the past.
IDAPI is only really necessary if you are using a custom configuration file for the BDE. This may cause a problem if multiple programs on the same computer try to use the BDE with different configuration files. It is recommended that other methods of modifying the BDE's setup are used, such as running code in the dBASE Users' Function Library (dUFLP) that will modify the BDE’s registry settings.
USERBDEALIASES Is a setting which allows a standard user to create a User Alias that gets saved to the user's ini file.
A standard user will NOT be able to add a regular BDE Alias that gets stored in the BDE config file (idapi.cfg), unless the user is given administrator privileges OR is put in a custom user group that has full access to the BDE's registry keys and the folder containing IDAPI.cfg.
The alternative is to deploy your app with one of the following:
- an .ini file containing User BDE Alias settings that the runtime will auto load when starting your application.
- a custom routine that your program runs to create on-the-fly any User BDE Aliases needed while your program is running.
To use the .ini file option, add lines similar to the following:
[UserBDEAliases]
0=SomeAlias
1=SomeODBCAlias
[SomeAlias]
Driver=DBASE
Options=PATH:C:\SomeAliasFolder
[SomeODBCAlias]
Driver=<SomeODBCDriverName>
Options=<Connection String Settings for ODBC Driver>
dBASE will support up to 10000 User BDE Aliases numbered 0 thru 9999. However, this probably exceeds the maximum size of an INI file section supported by Windows which is documented to be about 32KB.