PDoc-Builder 5 Configuration

All code relating to third part components will be maintained in the \CBuilder5\Projects directory. This library set must be maintained to the current versions of modules being used for releasable builds. The component pallette will be restricted to a subset of the total available so as to maintain compatibility between applications.

Packages to be installed in Component Pallette
 

1/ These are used in particular applications and attempts will be made to remove them as convenient.
2/ This is used to provide access to Word 97 for generation of appointment letters from CMS8.
3/ Latest version of Quickreport to be obtained.
4/ This is currently a design time only package, and the software is integrated into the application. The runtime library will be used as soon as available.

Project Directory Structure

Builder 5 is installed in the base \CBuilder5 directory and all Borland related components are maintained in that location. The \CBuilder5\Projects directory is only used for third party component libraries.

A separate \Projects directory is maintained for all application development, and sub-directories are maintained for each major release of an application. ( eg CisOperator5_4 ). Copies of each sub-release are maintained within that directory under a \Archive subdirectory. There are also sub-directories for \Final, \Inter and \Old, and projects are set up to use these directories for both the output program, and for intermediate code and pre-compiled headers. The intention is that a program module should be capable of being copied to an alternate developement machine and will compile to create the same code in the same locations.

When a module is released for use by others, the source code set ( in the base project directory ) is zipped up to provide an archive copy of the build material. By convention, this is titled 'Soft-<Project><Release Letter>.ZIP', and the finished executable is similarly zipped up with the title 'Exe-<Project><Release Letter>.ZIP'. These are initially stored in the \Archive sub-directory, and will be copied to the master archive as required. For convenience, a copy of the executable is also maintained in the \Old sub-directory which can be used to check fault reports since they are available to use as required.

It is anticipated that intermediate and test builds of modules will be required, in which case an additional project directory will be created, allowing the current build to be maintained until superceeded. Where a component library changes, this will be maintained in a similar manor so that the correct environment can be recreated as required to work on older versions of a module, but the intention is that if a module is required to be modified, the latest libraries will be used for the new build. To that end, where possible new library builds will have a different file name to allow them to co-exist. This may mean that we do not change a library if it can not co-exist with the current copy.

Standard Project Outline

All modules will follow the same basic outline unless there are specific reasons not to do so ( such as the DC Clock Module ).

The first form will be a startup window with Postfield Logo and progress message display. This will then load a data module which will access the main registry information and build the connections required to any actual database tables. This approach allows the main form to be modified prior to actual creation, and all links to be tested early in the loading cycle. The 'OneCopy' routine is located in the startup form, and so no main form information is accessed if there is already another copy of the program running. A 'Kill' flag on the startup form is used in other modules to ensure that the application is closed as soon as a problem is encountered, and preventing any other forms from being loaded. ( Check the example project for how to use this properly ).

At present communications to the LocalHub is managed via a socket connection on the main form. For neatness this could be moved to it's own form, but since only a small amount of code is required to implement it, and most of the commands are required to or from the main form this may be counter productive. The sample project provides the basic started and stopped messages to the LocalHub and respondes to a stop command from the LocalHub. Other command messages can be found in the Network Protocol document.