Overview

A 4D component is a set of 4D objects representing one or more functionalities that can be installed in different databases. For example, you can develop a 4D e-mail component that manages every aspect of sending, receiving and storing e-mails in 4D databases. 

Creating and installing 4D components is carried out directly from 4D. Basically, components are managed like plug-ins according to the following principles: 

• A component consists of a regular structure file (compiled or not) having the standard architecture or in the form of a package (see .4dbase Extension).
• To install a component in a database, you simply need to copy it into the “Components” folder of the database, placed next to the structure file or next to the 4D executable application. You can use a shortcut (Windows) or an alias (Mac OS). To uninstall it, simply remove it from the folder.
• You cannot use standard tables or data files in 4D components. However, a component can create and/or use tables, fields and data files using mechanisms of external databases. These are separate 4D databases that you work with using SQL commands. For more information, refer to About external databases. 

Creating components requires an appropriate license. On the other hand, installing and using components in a 4D application is not restricted.

The component management mechanisms in 4D require the implementation of the following terms and concepts:

• Matrix Database: 4D database used for developing the component. The matrix database is a standard database with no specific attributes. A matrix database forms a single component.
  The matrix database is intended to be copied, compiled or not, into the Components folder of the 4D application or the database that will be using the component (host database).

• Host Database: Database in which a component is installed and used.

• Component: Matrix database, compiled or not, copied into the Components folder of the 4D application or the host database and whose contents are used in the host databases.

• Project Form: Form not linked with a table. Project forms are particularly suitable for component generation. For more information about different types of forms, refer to Table forms and project forms.

• Table Form (also called a “standard” form): Form associated with a table. This type of form cannot be used in a component.

It should be noted that a database can be both a “matrix” and a “host,” in other words, a matrix database can itself use one or more components. However, a component cannot use “sub-components” itself.

By default, all the project methods of a matrix database installed as a component are potentially visible from the host database. In particular:

• The shared project methods are found on the Current form table of the Explorer and can be called in the methods of the host database (see Sharing of project methods). Their contents can be selected and copied in the preview area of the Explorer. They can also be viewed in the debugger. However, it is not possible to open them in the Method editor nor to modify them.
• The other project methods of the matrix database do not appear in the Explorer but they too can be viewed in the debugger of the host database.

To protect the project methods of a component effectively, simply compile the matrix database and provide it in the form of a .4dc file (compiled database that does not contain the interpreted code). When a compiled matrix database is installed as a component:

• The shared project methods are shown on the Current form table of the Explorer and can be called in the methods of the host database. However, their contents will not appear in the preview area nor in the debugger.
• The other project methods of the matrix database will never appear.