Example files available in bu03isus.exe
NOTE: This document was originally written for Visual dBASE 7.0/7.01, it has been updated for dB2K (release 1) to include information about new properties, events, etc., and any new controls since the document was first written. If a control is new it will be noted. In updating this document, the images were left "as is" unless it was felt to be absolutely necessary to change them ...
In addition, this document refers to dB2K a lot, but unless it is about a dB2K specific aspect, the text can be used for Visual dBASE 7.0 through Visual dBASE 7.5.
Special dB2K Note: If you are working with dB2K, there is a document on working with Inno Setup that was written specifically for dB2K. It is on your dB2K CD, in the INNO folder. This covers deploying the application, you may want to read the parts of this document that discuss building the executable and preparing it for deployment.
Any developer who needs to finish their application is going to run into the fact that the process of Compiling and/or Deploying their application is not well documented in the manuals or online help (although this process is better documented in dB2K than in previous versions).
This process is actually pretty simple, but it does not appear that way the first time you try it.
You are best off using the Project Manager to set everything up -- it may take a bit of work, but in the long run, you are ensured that everything is set the way it should be.
The instructions in this document are based on a simple application, with local tables. There are more detailed things that can be done (and should be if you are working with non-local tables), and the places to handle these are pointed out, but not detailed here.
Following along, you should be able, when done, to create a project file, build/compile your application, and use InstallShield Express to create your deployment disks. Note: for dB2K developers, please see the paper noted above on using Inno Setup to create your deployment ...
Special Sections:
Some Definitions
The following phrases can be a bit confusing to some folk, so
I thought I would attempt to explain them:
Add to Project File -- this phrase refers to adding any file you wish to, to your project file. In the case of any files that can be "compiled" by dBASE (creating a file with a .CO, .PRO, .WFO ... anything ending with "O" except for an Icon (.ICO) in the file extension), these files will automatically be included in the target executable (see below). Anything else, if you really must include it in the executable (some developers store empty tables or image files in the .exe and copy them out later), you must do so explicitly (see below).
Include in Target Executable -- this phrase refers to including a file explicitly in the executable. As noted above, it is possible to have the compiler in dBASE store an image file, or a table (or anything else) in the .EXE. The only real advantage to this is that if the user deletes a file needed by your application, you can have them execute some command that extracts the file, or have the application do it automatically (there is a variation on the COPY FILE command that can be used, we're not going to get into it here).
Deploy With Application -- this phrase simply means that you want InstallShield Express to deploy that file with the executable file and the tables you need deployed. This might include files like the .INI file, a BDE configuration file (.CFG), tables (and their .MDX and/or .DBT or other associated files), image files, icon files, and so on ...
First, if you are deploying an application that uses a BDE alias, you have to go through all the steps shown under the BDE part of the InstallShield Express setup below.
Second, if you deploy local tables to a directory other than the one your application is installed to, you must go through some steps in the GROUPS section below (in the InstallShield Express setup below -- Specify Components and Files).
Third, if you are using VdBASE 7 level tables, you should set the registry setting for TABLE CREATE (particularly if your application creates tables or issues ALTER TABLE commands, or even does a "COPY TABLE"). (This is covered toward the end of the InstallShield Express part of this document ...)
Finally, and this is the part we're going to discuss here, you may need to set up the default language driver for your application, and while you can do it in the registry settings (covered as above), you can also do it in a slightly less complex fashion:
[IDAPI] CONFIGFILE01=mycustom.cfgMake sure that this includes a path if the .CFG is deployed in a directory other than the one your .EXE is in.
And make sure when you include the files to deploy in the InstallShield Express setup, that you include your .CFG file as well as your .INI file. (Specify Components and Files)
NOTE: Check the section that covers InstallShield -- it discusses ensuring all the correct BDE files are deployed. dB2K Users, the Inno Setup paper mentioned above covers this -- it's actually easier in Inno Setup ...
If you expect your deployed application to perform in the same manner as when you were developing it, you MUST deploy a .INI file. It needs to be the same name as the .EXE -- otherwise your application will not automatically read these settings (i.e., MYEXEC.EXE would require a .INI named MYEXEC.INI).
Some settings you should consider (see online help in dB2K 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 [IDAPI] CONFIGFILE01=mycustom.cfg
The "LDRIVER=WINDOWS" setting ensures that no matter what your application's BDE Driver your source code will be saved as ANSI. (There is a problem with this setting and the SoundEx() function -- otherwise this setting will enhance the speed of text processing immensely).
The "TALK" setting is very important (this is from Gary White who discovered it during one deploy he did) -- if Talk is not set OFF (either here or in your code), there will be a serious performance degradation, as Visual dBASE will go through the motions of echoing comands to the command window.
The "CommandWindow" settings are there just to be sure there are no other problems -- Gary discovered his application was going unstable without that (probably related to the TALK settings).
The "ComponentTypes" section may cause some datatype mismatch errors if not included, particularly if you are using the grid component on your forms. You should copy the section shown above from your own VDB.INI, as you may have different settings than those shown above.
The "IDAPI" section is based on the previous part of this document -- if you are not deploying your own custom .CFG file for the BDE, do not put that into your .INI file! dB2K users -- note that you may not need to deploy a custom .CFG file, see details in Inno Setup paper ...
Encrypted Tables
If you are working with encrypted tables (using the dBASE PROTECT command to
do so), you will need to deploy the DBSYSTEM.DB file, but you also need to have
an entry in your .INI that looks like:
[CommandSettings] DBSYSTEM=D:\PATH
Where "D:\PATH" is the path to the directory where you are deploying this file to. If you already have a "[CommandSettings]" section (see above), just add the "DBSYSTEM" entry. If you are deploying the DBSYSTEM file to the same as your application you can set this to "." (i.e., DBSYSTEM=. ) -- the "." stands for "current directory" ...
NOTE: you will see, when you right click on files in the pane, a couple of options:"Exclude from Build" -- only use this if you don't need a specific program, form, or whatever to be a part of the .exe. (Example: I have a program I use called SETUP.PRG - this is used to ensure that when I am coding that various .CCs and procedure files are available -- but I don't need it to be compiled into the .EXE, as the statements involved are called in my startup program ...)
"Include in Target Executable" -- this is deceptive -- it looks like you need to actually select each item to be included -- however, if a program, form, report, or other compileable file (datamodules, sql files, custom controls/ forms, etc.) is in the list, the .??O or .?O file will be automatically included in the .EXE file, and you do not have to do anything. The only reason for using this is if you wish to include tables, .DLLs, images ... in your .EXE (a trick some developers use to hide tables from the user ... we won't get into that here).
Right click in the project
manager's left pane, and select:
Project Properties
You will see a dialog with three tabs:
Project
Select the "Build" menu, select the menu item: "Build myapp.exe" (where "myapp.exe" is the name of your application)
Note that from the same menu you can execute the .EXE file, which can be useful for testing, and you can debug it from the menu as well ...
There are actually two steps here -- the first compiles the individual files to their "pcode" (the .WFO, .PRO, etc.). A dialog will show that this process is complete, and you must click "OK" to continue to the actual creation of the .EXE. The amount of time it takes to generate the .EXE will vary based on how complex it is -- have some patience here ... That's all there is to compiling your application (deceptively simple, eh?) ...
If you set up a log file (see above, under "Preparing the Application"), any errors (or warnings) should appear in the log file.
NOTE: If you have paths to custom controls, header files, and so on (such as: C:\PROGRAM FILES\dBASE\DB2K 01\CLASSES\SEEKER.CC ), the path is removed from the compiled version. PROBLEM: if you do not include the custom controls in your list of files in the Project, they will not be in the executable, and when you run the executable, errors will occur.
This is where things can be confusing -- InstallShield's help isn't as helpful as it could be (at least not until you've used InstallShield more than once), so here is a step-by-step walk through the different options based on a couple of installations I've created.
Unless you are very sure of yourself, you should use InstallShield Express for this, as there are registry settings (besides the ones mentioned later in this document) that are set automatically by InstallShield Express, as well as the fact that ISE handles many other things automatically. Deploying an application is not as simple as copying the .EXE and tables to someone else's computer (and hasn't been since the DOS days) ...
Select the "Build" menu, and "Create Install Program ..." (at the bottom of the menu). (You can also go straight to InstallShield Express from the "Start" menu in Win 95, 98 or NT 4 ...) If you have not installed InstallShield Express, then this will not work, obviously ...
You will see InstallShield Express come up -- this is a version created for Visual dBASE 7 in cooperation with Borland/Inprise/dBASE, Inc.. It handles things very nicely once you get used to it.
NOTE: If you have Visual dBASE 7.01, you should make sure you have InstallShield Express for Visual dBASE 7, version 2.01 (or later if they give us a new version -- this is wishful thinking on my part, not any implicit promise from InstallShield). To find the version number simply bring up the Help | About dialog ...
When you first bring up InstallShield Express, it assumes you're doing a new install, which is correct. After you've done one, the dialog will change a bit, but should be pretty obvious. Click the 'Ok' button, and move on.
Your best bet is to start at the top of the checklist provided (this is the "working screen" in InstallShield Express), and work your way down. You can click on the text or the little arrow buttons on the left of the text to get an option to come up.
The screen itself is a checklist, which brings up dialogs to actually set the various parts of the Install when you click on individual checkboxes. A discussion (with varying amounts of detail) follows for each section:
C:\PROGRAM FILES\Company Name\Application Name\application.exe
If you take it out/leave it blank, note in the last entryfield on this screen that you end up with two backslashes next to each other (you will need to remove one). (And when you actually finish the process, and create the deploy disks, you will get a warning -- but this is ok ... the install works fine.)
<ProgramFilesDir>\company name\application name
NOTE: If you do not want the application installed under C:\WINDOWS\PROGRAM FILES\... then replace the entry:
<ProgramFilesDir>
with:
<WINDISK>
This will install
to C:\Company Name\Application Name
(This information courtesy of Stefan from InstallShield)
If you do not wish the "Company Name" to be part of the path, you can remove it, but see the section on "Company" above about extra backslashes ...
Main Title -- this is where you specify either text (default) or the bitmap to display. InstallShield will check the bitmap definition, and if it contains more than 16 colors it won't accept it.
If you do have a valid 16-bit logo, you can specify where it should display on the main screen for InstallShield.
You can also set the background color of the main screen for InstallShield. Unfortunately, you can't preview it here -- you can do that later and come back here and change it, however ... (Warning - the "Solid Green" option looks horrible with the text being white -- you have no control over the white text ...)
Note that if you leave out the company name, the Win 95 Uninstall capability will not be setup.
When done, click the "OK" button. At this point, the items in this heading are all checked.
NOTE: The following assumes you are using BDE 4.5 -- this is the version that ships with Visual dBASE 7.0 and 7.01. If you are using BDE 5.01, see instructions later in this document, as you will need to actually modify your InstallShield Express setup.
NOTE: If you do ANY database/table access at all, you are using the BDE -- I am only saying this (which may be obvious to some) as some developers on the Visual dBASE newsgroups are/were under the impression that the BDE is only used for SQL or other tables -- any access of tables, even if it is just "use sometablename" requires the BDE.)
If it is checked, the button "Settings ..." is enabled, and you should take a look at that:
You get a dialog (automatically) where you can select "Full BDE" or "Partial".
According to the folk at InstallShield, unless you are absolutely positive that you do not need a "Full BDE" installation, you should select this option. If you install to a site with an older version of the BDE (i.e., Corel Suite, or some other application), you may run into problems unless you do a full BDE install.
If you are using the OODML at all in Visual dBASE 7, and you are using .DBFs (normally, although you might not be), you are also using SQL, and .DBs (.DBs? Aren't those Paradox tables? Yes -- but the local SQL engine actually uses temporary .DBs even if you don't think you are doing anything with them ...). It is generally a good idea to assume nothing and just install the full BDE.
If you are using the database classes and insist on using a partial install, make sure you select the SQL part of the BDE -- otherwise your database classes will not work. If you do not use the database classes it may not be necessary, but remember that reports and labels must use the database classes, so even if you don't use them anywhere else, you are using them there.
(NOTE: After testing, if a user has BDE 32 from, say Corel WordPerfect 7, you need to do a FULL BDE install, or you will get errors.)
After all those warnings, I cannot stress strongly enough: you should not use the "Partial BDE" installation ...
When you click the "Next" button you can set up your BDE aliases -- if you use these, this is a vital part of the installation.
If you need to set up BDE Aliases:
- Click "New" on the BDE Aliases screen
Enter the name of your alias, click "OK"
(Repeat if multiple aliases)
Click the "Next" button
- Click the "Next" button again (do not create the .CFG for 16-bit applications -- this option makes no sense for VdBASE 7 applications, as you cannot deploy a 16-bit version ...)
- You must have a name, an alias, and a type for each BDE Alias, and this screen is where you define them. You may seriously want to check help for this (click the "Help" button). You can use identifiers used by InstallShield Express to for the path of your alias. If your path for the tables (this assumes local tables) is the directory the application is installed to, enter:
<INSTALLDIR>
If the directory is under the one you install to (i.e., MYDIR\TABLES), use:
<INSTALLDIR>\TABLES
For someplace else, check the online help. There are a bunch of directory identifiers and the online help explains them all with some very good detail.
(Repeat for each alias you are setting up)
Click the "Next" button
- Click the "Finish" button
If you do NOT need to set up BDE Aliases:
- Click the "Next" button
- Click the "Next" button
- Click the "Finish" button
THIS IS VERY VERY IMPORTANT!
The way to do this is to use the "Launch Explorer" button, and drag any files you need to deploy into this folder.
NOTE: If you keep your files in separate folders under the main application, like a TABLES folder or something, you should click on the "Add Group" button and once you have completed that process, open that group and then drag your tables to that folder ... In addition, check the BDE settings if you are using an alias for this.IF the group is to be placed directly under the <INSTALLDIR>, you need to set this value in the combobox, and then add: "\TABLES" (or whatever name is necessary for the executable or the BDE to find the directory), ex:
<INSTALLDIR>\TABLESNote that if this is for your tables, the path should match the BDE Alias you set up previously.
ENCRYPTED TABLES: If you are using the dBASE PROTECT command to encrypt your tables, make sure that you deploy the appropriate DBSYSTEM.DB file, and see the notes in the section on .INI files toward the beginning of this document.
Click 'OK', and again you should see these options checked on the yellow checklist.
BDE Installation Failures
Note that there are several different parts to what is shown here, so if one solution does not fix your problem, try reading on ...
NOTE: The following has not been tested by the author, but was posted in the newsgroups by Rick Miller (12/30/1999). This is one possible solution to BDE installation errors ("BDEEngine Error", "Merging configuration files failed", "Language Driver not found" ...). The idea is to make sure that the deployer knows to grab all of the correct files, which means doing it manually.The following is a listing of files that need to be in the groups shown (in the square brackets) with the dates listed for Visual dBASE 7.01 (and BDE 4.5). You can set these by using the same information as shown above (for placing specific files in specific 'groups') ... The information on the BDE 5.01 was provided by Gerald Lightsey.
NOTE: See the section at the end of this document on working with BDE 5.01 ... it has provided some extra challenges for users of Visual dBASE 7.01 and InstallShield, but a few folk have successfully worked out these problems, and details are given there.
[Runtime Files] Visual dBASE files CTL3D32.DLL 07-13-95 RESOURCE.DLL 03-11-98 VDB70009.DLL 03-11-98 VDB7RUN.EXE 03-11-98 [BDE/IDAPI] BDE 4.5 BDE 5.01 BDEADMIN.EXE 11-14-97 10/10/98 BDEADMIN.HLP 11-14-97 06/09/98 BLW32.DLL 11-06-97 10/10/98 IDAPI32.DLL 11-14-97 10/10/98 IDAPINST.DLL 02-21-96 11/14/97 IDASCI32.DLL 11-14-97 10/10/98 IDBAT32.DLL 11-14-97 10/10/98 IDDA3532.DLL 11-14-97 10/10/98 IDDA032.DLL 11-14-97 10/10/98 IDDBAS32.DLL 11-14-97 10/10/98 IDDR32.DLL 11-14-97 10/10/98 IDODBC32.DLL 11-14-97 10/10/98 IDPDX32.DLL 11-14-97 10/10/98 IDQBE32.DLL 11-14-97 10/10/98 IDR20009.DLL 11-14-97 10/10/98 IDSQL32.DLL 11-14-97 10/10/98 BDEADMIN.CNT none 06/09/98 [BDE/IDAPI BLL] BDE 4.5 BDE 5.01 CEEUROPE.BLL 11-06-97 11-06-97 CHARSET.BLL 11-06-97 11-06-97 EUROPE.BLL 11-06-97 11-06-97 FAREAST.BLL 11-06-97 11-06-97 JAPAN.BLL 11-06-97 11-06-97 OTHER.BLL 11-06-97 11-06-97 USA.BLL 11-06-97 11-06-97 [BDE/IDAPI.CNF] BDE 4.5 BDE 5.01 IDAPI32.CNF 02-24-97* 11-14-97 * Note that my copy of this file is dated 02/04/96 and it has worked fine for my deployment ... I am not sure why Rick gave this date ...
In addition, Rick points out the following if an installation fails due to BDE errors. This correction is based on the Corel Suite (WordPerfect, etc.), or some Lotus Products. He states that in the worst case scenario to date, they had a "corrupt Corel Database engine" (Corel uses the BDE ...). The solution that was used was the following:
- Uninstall the application and Corel Suite
- Re-start the computer
- Delete the registry keys (REGEDIT) for:
Local Machine/Software/Borland/BLW32
Local Machine/Software/Borland/BDE
Local Machine/Software/Corel- Re-start the computer
- Delete all Corel Application Files
- Delete all BDE files
- Install the Application
- Install the Corel Suite
To date, this solved the problem ...
"Merging the configuraton file has failed" error
This information is based on a technical document at the InstallShield support website (see below) -- the article is Q100670.This message may be displayed due to one of several reasons:
- The target machine's pre-existing IDAPI32.CFG file is read-only or is inaccessable (in use, perhaps).
InstallShield Express finds the existing IDAPI configuration by reading the location from the:
HKEY_LOCAL_MACHINE\SOFTWARE\Borland\Database Engine\key in the registry (in the CONFIGFILE01 value).If the .CFG file is not in this location, you will need to update the users' registry to point to the correct location, or delete this registry key.
If the .CFG file is in this location, shut down any application that may be using the BDE, and/or check to see if the .CFG is set to read-only (if so, change that quick!).
- The target machine's BDE Administrator is running during installation. If this is the case, the BDE will not allow the .CFG which is open to be modified. (Shut down the BDE Administrator and try the installation again.)
- The IDAPI configuration file on the target machine is corrupt. To test this, launch the machine's BDE Administrator and open the configuration file from the path shown in the registry (see first point above). Try using the program's "Merge Configuration ..." option (under the "Object" menu) to merge another configuration file with the IDAPI file (try the IDAPI32.CNF located in the InstallShield Express "Redist" subdirectory).
Also try saving the machine's IDAPI32.CFG as a new temporary name and open the IDAPI.CNF in the InstallShield Express "Redist" subdirectory, save as "IDAPI32.CFG", and re-run the installation. You can see if this works with a "Clean" configuration file.
The only drawback to doing the above is that any prior settings may be lost -- however, if the .CFG was corrupt then those settings may have already been lost ...
Note: There are a variety of documents at the InstallShield website that deal with BDE and other installation issues that may be useful -- if the information you need is not here, try going to this site:
http://support.installshield.com/kb
(This information provided by David Love -- thanks!)
Need a new IDAPINST.DLL for BDE 5.0/5.01
In addition to the information given above, a discussion from the Visual dBASE 7 newsgroups including Stefan from InstallShield revealed the following:
The IDAPINST.DLL file that ships with InstallShield Express 2.01 cannot handle the BDE 5.0 and later versions (5.01, 5.02).There is a new dll at this website:
http://www.tdag.org/downloads/idapinst50.zip
When you download this, unzip it, rename the version in your "IS Express for Visual dBASE\redist" directory to "idapinst45.dll" (so you still have it).
Copy the new version (idapinst50.dll) over to that folder and rename it to idapinst.dll.
When you deploy the application this will resolve a lot of problems.
"Merging the configuraton file has failed" error
According to Stefan at InstallShield, this error commonly occurs if there was a previous BDE installation and the following two registry keys still exist:HKEY_LOCAL_MACHINE\SOFTWARE\Borland\BLW32
HKEY_LOCAL_MACHINE\SOFTWARE\Borland\Database EngineIf these two keys exist in the registry, try deleting them and re-run the installation.
One Other Solution If Nothing Else Works ...
According to Steven Choi, the only solution that has worked for him is to create the installation using the BDE 4.5 that ships with Visual dBASE 7, and then use the BDE 5.01 upgrade set on the client's machine after installing your application (with BDE 4.5). This upgrade set is the downloadable stuff from the borland.com website ...
Still No Fix?
Unfortunately these are the only solutions I am aware of to date. If none of these solve your particular situation, please post the exact details in the Visual dBASE newsgroups, and hopefully someone will be able to help ...If you find a solution to a problem that is not mentioned here, it would help the whole of the dBASE community if you would share it -- drop me an email and I will try to incorporate it into here at the earliest possible opportunity.
Items that are blue are the items that I feel should be included (this is just my opinion):
Click 'OK' and move on ...
NOTE: After some work tinkering and trying things, it may not be necessary to do all of the settings below, except for the "Table Level" -- especially if your code uses local SQL commands to CREATE TABLE, COPY TABLE, ALTER TABLE, and those tables need Visual dBASE level 7 table settings (Referential Integrity, Autoincrement fields, etc.). The Language Driver can be set from the BDE Administrator and such as described at the beginning of this document.
BDE Registry Settings
Registry changes can be tricky, but after some tinkering, the following keys values can be set in the registry via InstallShield that may be very important for the BDE. I am attempting to put excruciating detail here (NOTE: the "Value Data" for registry values -- if quotes are shown, enter the quotes -- if they are NOT shown, do not enter them!).
- First, select the KEYS tab. Next, click on:
HKEY_LOCAL_MACHINE -- click on the + to the left, so it expands
Software -- ditto
Borland -- ditto- Click the "Add Key" button, and enter in the "New Key" entryfield (NOTE -- CASE IS IMPORTANT!!):
Database Engine\Settings\DRIVERS\DBASE\INIT
- Click the "OK" button
Click on the INIT item that is down the tree now (this will make more sense if you look at it), and then click the "Registry Values" tab of the notebook control.LANGUAGE DRIVER:
Click the "Add Value" buttonWhere "nameofdriver" is equal to whatever is currently in your own registry (you will need to run REGEDIT to see this). Example -- Western European ANSI is: "DBWINWE0" (that's a zero)
- For "Value Name" enter: LANGDRIVER
- For "Value Data" enter: "nameofdriver"
- Click "OK"
TABLE LEVEL:
(See notes above -- this may be the only setting you really have to be concerned with)
- Click back on the "Registry - Keys" notebook tab.
- Make sure you are on "DBASE" (this is the one that "INIT" is on in the tree).
- Click the "Add Key" button, and enter in the "New Key" entryfield:
TABLE CREATE
- Click the "OK" button
- Click the "Registry - Values" notebook tab.
- Click the "Add Value" button
- For "Value Name" enter: LEVEL
- For "Value Data" enter: 7
NOTE: no quotes ....- Click "OK"
DEFAULT DRIVER:
Click the "OK" button to go back to the checklist.
- Click back on the "Registry - Keys" notebook tab.
- Make sure you are on "Settings".
- Click the "Add Key" button, and enter in the "New Key" entryfield:
SYSTEM\INIT
- Click the "OK" button
- Click the "Registry - Values" notebook tab.
- Click the "Add Value" button
- For "Value Name" enter: DEFAULT DRIVER
- For "Value Data" enter: "DBASE"
- Click "OK"
- Click the "Add Value" button
- For "Value Name" enter: LANGDRIVER
- For "Value Data" enter: "samesettingasbefore"
- Click "OK"
This is the same as the language driver set above.
You should select the application's executable, or the user will end up with an empty Group folder, which can be disconcerting at best.
Click on "Run Command", and select the executable from any files listed. You should see the icon specified for the .EXE. You could change it if you wanted to. You could change the text that appears in the group folder for the executable ... and you can modify how the application starts up (Maximized, Minimized, "Normal").
Note that this will create directories under your application directory ...
NOTE: If you are working on a Win 95 or Win 98 computer, this option appears to work fine. I have seen reports, however, of users who were using NT 4.0 and either the operation hung up and stopped working on disk 1, or it took 25 minutes to complete (which is silly).You can always use the Windows Explorer to copy the contents of the disk images to floppies ... (or even the DOS COPY command)
Letting InstallShield
Handle It
InstallShield Express will automatically register any file that contains the
"OLESelfRegister" string in it's version resource. You can check for this by
using the Borland Resource Workshop or Microsoft's Visual C++, looking for:
VALUE "OLESelfRegister", ""
If creating your own, you can add this. See the online help for InstallShield for exact details ("Self registering ...").
You can also add this section to the SWDEPEND.INI file that is created for your InstallShield Express setup
[DLLNAME.DLL] Register=$(DLLSelfRegister)
Change the "DLLNAME.DLL" to the name of your .DLL or .OCX. If this section already exists, you should add the "Register ..." statement.
You should also check the .OCX file's documentation for any dependencies that it may have. Any .DLL files that are needed for your .OCX to execute properly need to be registered before the .OCX is, so check the order in this .INI file. In addition, these .DLL files must be added to a file group in your Express setup (see above -- Groups and Files dialog) before the .OCX file is, as they will be registered on the target computer in the order they are added to the group!
Manually Handling These
In Your Own Code
In addition to the above, you may want to just do this yourself.
An example of this is in VESPER7 (found at the author's web site and mirrored to some other web sites out there). This is free-ware sample code.
The basics of this are covered here.
Visual dBASE 7 ships with some registry API calls found in these files -- WINREG.H and REGISTRY.PRG. (WINREG.H is in the INCLUDE directory that ships with Visual dBASE, and REGISTRY.PRG is in the SAMPLES directory ... don't ask me why they were placed in these different directories, but ...)
The file "winreg.h" contains definitions, and "registry.prg" contains actual extern calls to code.
The fun part is that you need to check to see if the registry key is set. In the startup program for VESPER7, the following is contained in the Open method (for a calendar control created in Delphi 3 and converted to an OCX file):
// necessary for Registry stuff: #include <winreg.h> set procedure to registry additive // Check to see if the Calendar has been registered // and if not, register it oReg = new Registry( HKEY_CLASSES_ROOT, ; "CalendarXControl.CalendarX" ) // if key referred to by "oReg" does was just // created, then we need to register the control: if ( oReg.newlyCreated ) run( "regsvr32 /s calendar.ocx", false ) endif // check to see if the registry key is empty -- if // so, something didn't work ...: if empty( oReg.queryValue( "" ) ) msgbox( "Registry setting for Calendar control not set --"+; "Do not try running calendar -- an error will "+; "occur and may cause the program to crash. Contact "+; "Ken to get a fix ...", ; "Didn't work!" ) endif
If the registry key is empty, it was probably created when we checked to see (oReg.newlyCreated) if it existed. The registry API calls being used will create the key when checking for it. If it didn't exist (i.e., oReg.newlyCreated actually returns a logical value -- true means we just created it), then we run a DOS program (odd, but true) -- the /s parameter simply runs the program in "silent" mode -- no dialog box will appear -- that will register the ocx ( "regsvr32.exe" -- note -- this program normally resides in your \WINDOWS\SYSTEM directory -- if it doesn't, or if your DOS path does not include that directory, this will not execute). (Note: there is now a DeleteKey() method in the REGISTRY object -- this didn't used to be there -- at the time Vesper was actively being worked on Visual dBASE 7.0 was the latest version -- this was added for 7.01 ... you could delete a registry key if it was empty ...)
The last thing we do is check to see if the key is still empty, and if it is, we display an error. This error is usually because the program doesn't exist (not likely, but it is possible -- "regsvr32.exe" is installed with Windows 95, 98 and NT); or more likely is the fact that your DOS path does not include the \WINDOWS\SYSTEM directory, which is where this program is installed to. You can get the user to step out to DOS and type:
regsvr32 myocx.ocx
and it should display a (windows) alert dialog stating that it worked. (The /s flag in the RUN() call above simply runs this in "silent" mode -- so that when the start program executes, the user never has to even be concerned with the details ...)
NOTE: Using REGSVR32.EXE you can actually remove an OCX's (or probably even a .DLL's) entries in the registry by using the /U flag (uninstall).
As noted in the InstallShield part of this discussion, if your .OCX has dependencies on other .DLLs, you need to install them first -- otherwise the .OCX won't install properly.
"Network deployment is a two step process. You must install the program and you must install the data files. I have not found a way to do this with a single InstallShield deployment. I build one deployment that does not include any shared tables. The tables that will reside on a shared network drive are a separate InstallShield project. The data files project may, or may not include setting up the BDE alias. The start-up program checks for the existence of the BDE alias, if it is not found, allows the user to locate the files. Once the files are found, the program creates the alias on the users' machine. A simplified version of the code for that would look something like the following, although a more complete version would check for the existence of all the files necessary."
//Code as provided by Gary White, some of it is // based on code by Romain Strieff and Jim Sare if not databaseFound( "yourDatabaseName" ) cPath = getDirectory() CreateAlias( "yourDatabaseName", cPath ) endif function dataBaseFound( cDatabase ) local d, dbArray d = new database() dbArray = d.getSchema( "Databases" ) release object d return dbArray.scan( cDatabase ) > 0 function CreateAlias(cAliasName,cPath) //Creates a DBF Alias if type("DbiAddAlias") # "FP" extern cint DbiAddAlias(; cHandle,; CPTR,; CPTR,; CPTR,; clogical) idapi32 endif return DbiAddAlias(null,; DBCSToSBCSZ(cAliasName),; DBCSToSBCSZ("DBASE"),; DBCSToSBCSZ("PATH:" + cPath),; TRUE)=0 // necessary for above Function DBCSToSBCSZ(c) LOCAL cTemp, x cTemp = Replicate(Chr(0), ((Len(c) + 1) / 2) + ; ((Len(c) + 1) % 2)) For x = 1 To Len(c) cTemp.SetByte(x - 1, Asc(SubStr(c, x))) EndFor RETURN cTemp
BDE 5.01 Deployment
The following is based
on work done by Michael Rotteck, who has done quite a bit of testing and work
with deploying the 5.01 version of the BDE.
For all of this to work properly, you need the InstallShield Express update to version 2.01 as noted elsewhere in this document. This is available from the dBASE, inc. website.
Next you need the file bu03isus.exe -- this file is now included with the DEPLOY7 document. This file is a self-extracting zip file, which will unzip files needed for a US deployment. Extract these files to a temporary folder.
See notes below if you are not using a US version of the BDE. You may want to backup the files you are over-writing with new ones -- see below.
If using Visual dBASE
Professional
If using Visual dBASE
Client/Server
Note that with the BDE 5.01 update you get new SQL links for Oracle 8 and Informix 9.
>From this point on, you should be able to deploy a new application with BDE 5.01 with no problems, see the rest of this document for the other details on deploying the BDE.
Already Created
Setup for BDE 4.5, Need to Modify for BDE 5.01
Michael suggests that to do this, you modify your installation
(this should be a one-time-only operation) in the following manner:
This will have created a setup without the BDE.
This should force InstallShield to re-evaluate the .CNF files and other files necessary to deploy the BDE, and you should now be able to deploy the BDE 5.01 version.
Non-US Versions of BDE
5.01
First off, get the Non-US version of BDE 5.01 from the appropriate Borland office
(i.e., Borland Germany, Borland Italy, etc.), and install it.
Next, if you do not do the following, you will get an error message stating "VDB70009.DLL not found". This is a US .DLL file, and you need to substitute the reference for InstallShield, so it installs the appropriate language version. The following steps should solve this problem.
Open the file SWDEPEND.INI in any text editor, and make the changes noted below:
Uses2=VDB70009.DLL
Change this to read:
Uses=VDB700xx.DLL
You will find in the Visual dBASE\BIN folder a file with a similar name, but the last two digits before the extension (before .DLL) will be different, based on your language. Change the 'xx' in the statement above to the appropriate .DLL name ... You can also use the following chart:
09 | English/US |
07 | DE /German |
0A | ES /Spanish |
0C | FR /French |
10 | IT /Italian |
11 | JA /Japanese |
Note that the "0A" and "0C" options use the number zero not the letter "O".
Uses2=IDR20009.DLL
Change this to use the appropriate .DLL found in your BDE folder -- the file will be named "IDR2nnnn.DLL" -- change the reference above to match this.
Uses2=IDR20009.DLL
Change this to use the appropriate .DLL found in your BDE folder -- the file will be named "IDR2nnnn.DLL" -- change the reference above to match this.
Save the file, and exit the editor. When you go to create your install disk sets, you should now be able to deploy your language-specific version of the BDE 5.01.
Don't forget that the Knowledgebase is full of other useful documents as well as this one ...
DISCLAIMER: the author is an employee of dBASE, Inc., but has written this on his own time. If you have questions regarding this .HOW document, or about dB2K you can communicate directly with the author and dBVIPS in the appropriate newsgroups on the internet..HOW files are created as a free service by members of dBVIPS and dBASE, Inc. employees to help users learn to use dB2K more effectively. They are edited by both dBVIPS members and dBASE, Inc. Technical Support (to ensure quality). This .HOW file MAY NOT BE POSTED ELSEWHERE without the explicit permission of the author, who retains all rights to the document.
Copyright 2001, Kenneth J. Mayer. All rights reserved.
Information about dBASE, Inc. can be found at:
http://www.dbase.com
EoHT: DEPLOY7.HTM -- January 30, 2001 -- KJM