The application Connector is a component designed to manage the start up sequence of an application and provide some general application functionality. It covers tasks from application initialisation, registration/licensing and database log in and log out, to retrieval of key application parameter values, passwords and quitting the application. A range of fail states indicate any problems preventing successful opening of the application (to an "idle" state) or issues with subsequent processing, allowing appropriate processing.

The Connector is one of several integrated components and forms working together to underpin application setup, application parameter storage and retrieval, string encryption and decryption, credential (password) management, database user security, database maintenance... and more.

This page is under construction

General Connector Usage

In terms of "connecting" to an application, the following snippets demonstrate the basic usage of a Connector. This by no means covers all that might be done with the Connector, or cover any of the many other procedures and functions the Connector provides "on demand". The samples use an instance of the Connector called SysConnector, which has been placed in the data module dmMainData.

1. OPENING: The connector is typically initialised (or "opened") when the main form is activated at start up. This cycles through a comprehensive sequence of events preparing the application for first use. See the description of Connector States below for more details.

2. SETUP: On first use (FirstIdle := True) an application might configure available options with respect to the logged in users permissions or role.

3. CLOSING: The application can be terminated explicitly using the Connectors Quit method.

If the user closes the main form, FormCloseQuery can call the Connectors Disconnect(Quitting: Boolean) method to implement the close down instead. To disconnect without terminating the application, use Quitting := False. Otherwise, terminate the application using Quitting := True. Either way, a "clean shutdown" is performed.

Both these methods fire the Connectors OnCloseQuery event, which can also be directly called via the SysConnector.CloseQuery method. If CanClose := False, details of the issue can be returned and (automatically) incorporated into a compound error message (as a qualifying "detail").

NOTE: Care must be taken to avoid a situation where it becomes impossible to disconnect the Connector (ie where CanClose is always False and always prevents terminating the application). This might be managed by presenting a "close down anyway" prompt.

Connector States

The Connector cycles through a sequence of "states" describing the start up procedure for an application. The states are represented by an enumerated type. Events are fired throughout the cycle allowing appropriate responses to each action implied by the various states.

A good way to start understanding the Connector is to trace the progression of the state sequence via the enumerated type (TConnectorState). Where applicable, the event used to implement the corresponding action and the fail state associated it is listed.

1. A connection action is returned by OnConnectionPrepare: caRejectSetup triggers the fail state csFailConnectionPrepare; in the absence of valid connection parameters, caSetup allows the user optional (prompted) access to a connection setup procedure; caLogin proceeds to a log in prompt; caConnect proceeds to an unprompted log in; caConnectionNA can be used where no connection is required by the application.

2. A TConnector descendant appropriate to the database server being used "knows" how to connect and the connection components to use. eg TIBXConnector connects to InterBase using the Interbase Express components. TIBFConnector uses FireDAC to connect to Interbase.

​