| Navigation: How To's and Troubleshooting > How to… >====== Creating a .DLL (Sub-Application) ====== |    |
This section describes the steps to create a program using one main application and several sub-applications compiled and linked as external.DLLs. It is written with Team Development in mind, so it describes some of the aspects of working in a multi-developer environment. Dividing a large project into multiple .DLLs provides many benefits:
·Each sub-application can be modified and tested independently.
·Developers can work on their portion of the project without interfering with others on the development team.
·Each sub-application can be compiled as a DLL and tested in the main program without recompiling the entire project. This reduces compile and link time.
·Future updates can be deployed by shipping a new .DLL, reducing shipping costs.
With this approach, each Team Member creates a separate .DLL that is called by a “master” application. This requires splitting the application into a “Main” executable and “secondary” .DLLs. The individual team members maintain separate application files for each component. The Team Leader creates a master application that calls the sub-applications and a “data” application that contains (and exports) all the File definitions and Global variables. Optionally, members can call procedures from another member's .DLL.
This method also requires extensive pre-planning of the “division of labor” between the various target files created by the application.
The following outlines a possible implementation of this strategy:
1.Create the data dictionary and set up the workstations as described above.
2.Create a “dummy” application to store and export all data declarations. All Global variables or structures and all file definitions are defined (and exported) in this application. Use the following settings:
In the Application Properties:
Dictionary File
The master dictionary residing on the network.
Target Type:
DLL
In the Application's Global Properties:
Generate Global Data as External:
OFF
File Control Flags
Generate All File declarations:
ON
External:
NONE EXTERNAL
Export All File declarations:
ON
3.Team members create their own sub-application .APP files, specifying the dictionary file on the network as the data dictionary, and a directory on the local drive as the default directory for the .APP file. Each team member specifies a different target file using the following settings:
In the Application Properties:
Dictionary File:
The master dictionary residing on the network.
Target Type:
EXE during the design and testing phase
DLL when releasing to the master directory.
Changing the Target Type enables procedures to be exported. Make sure that every procedure that is called by the master application or another .DLL has the Export Procedure check box in the Procedure Properties checked (the check box is only available after changing the target type).
In the Application's Global Properties:
Generate Global Data as External:
ON
File Control Flags
Generate All File declarations:
OFF
External:
ALL EXTERNAL
All Files declared in another .App:
ON
Declaring Module:
Leave this blank
In the Application's Module Tree:
Choose Application 
Insert Module, select External DLL, then select the corresponding .LIB for the .DLL containing the data definitions.
One particular .APP creates the executable which launches or calls library functions or procedures in the others. To the end user, this is the .EXE program to start when working with the complete application.
4.Team members synchronize their local directory with an equivalent on the network at the end of each day.
5.Team Members release their compiled and linked .DLLs to the Team Leader.
Each sub-application has a “dummy” frame (not exported) that calls the sub-application's procedures so the Team Member can test the sub-application by compiling it as an .EXE. Once it passes testing, the member compiles it to a .DLL by changing the Application Properties' Target File type to .DLL and releases the file to the Team Leader.
6.The Team Leader copies the released .DLLs into the master directory and creates a master .APP file which calls the entry point procedures in the .DLLs.
The Master .APP is typically just a bare bones application with just a splash screen and a main frame with a menu and toolbar. The .DLLs are called at runtime so you don't need to compile a large Master .EXE. The Master .APP should have the same settings as the sub-applications except that it is always compiled as an .EXE.
The master .APP should have these settings:
In the Application Properties:
Dictionary File:
The master dictionary residing on the network.
Target Type:
EXE
In the Application's Global Properties:
Generate Global Data as External:
ON
File Control Flags
Generate All File declarations:
OFF
External:
ALL EXTERNAL
All Files declared in another .App:
ON
Declaring Module:
Leave this blank
In the Application's Module Tree:
Choose Application Insert Module, Select External DLL, then select the corresponding .LIB for the .DLL containing the data definitions.
Choose Application Insert Module, Select External DLL, then select the corresponding .LIB for the sub-application .DLL. Repeat this step for each sub-application.
For each procedure the main application calls, edit the ToDo procedure as follows:
Template:
External template.
Module name:
Select the corresponding .LIB for the DLL drop down list.
If necessary delete any empty generated modules.
7.The Team Leader compiles the master .APP and tests the calls to the DLLs.
8.The Team leader repeats the last step on a periodic basis until all work by all developers is complete, and the entire application can be tested.