Component installation and compatibility

To install a component in a 4D database, simply copy the structure file of the matrix database into a Components folder available for the host database. You can put the Components folder in two places:

• At the level of the 4D executable application: in this case, the components are available in all the databases opened by this application.
• At the same level as the database structure file: in this case, the components are only available in this database.

For more information about this, refer to Location of PlugIns and Components folder.

4D looks for matrix databases of the .4db (interpreted matrix database), .4dc (compiled matrix database) or .4dbase (package type matrix database) types in the Components folder. Other elements, in particular data files or user structure files (.4DA), are ignored. You can use aliases or shortcuts to these matrix databases. This can be particularly useful during the development phase of a component since any changes made in the matrix database are immediately passed on to all the host databases. 

The Components folder can contain any custom files or folders that are necessary for the operation of the component (xliff, pictures, and so on). On the other hand, it cannot contain plug-ins or Components subfolders. If either of these items are present, they will be ignored by 4D. The plug-ins used by the components must be installed in the host database or in 4D itself.

A host database running in interpreted mode can use either interpreted or compiled components, in Unicode mode or not. It is possible to install both interpreted and compiled components in the same host database. However, if several compiled components are present, they must be executed in the same Unicode mode.

A host database running in compiled mode cannot use interpreted components. In this case, only compiled components can be used. Similarly, the Unicode mode must be the same for host databases and components. 

The following table summarizes the component use possibilities:

(*) If several compiled components are installed, they must operate in the same Unicode mode. 

Notes:

• An interpreted host database that contains interpreted components can be compiled if it does not call methods of the interpreted component. Otherwise, a warning dialog box appears when you attempt to launch the compilation and it will not be possible to carry out the operation.
• In general, an interpreted method can call a compiled method, but not the reverse, except via the use of the EXECUTE METHOD and EXECUTE FORMULA commands.

For more information about inter-component and host database-component exchanges, refer to Interaction between components and host databases.

An interpreted component developed under Mac OS can be installed in a Windows environment and vice versa.
On the other hand, compiled components must be executed on the same type of platform they were compiled on, unless they were compiled for both platforms.

Components installed in the server database are automatically transferred to the client machines via a mechanism resembling that of plug-ins. 

We do not recommend modifying a component in client/server mode since the changes are stored locally and the component will not be updated on the server machine.

The components are loaded when the host database is opened.

• If a component contains compiled code and interpreted code that do not correspond, an error message is displayed and the component is not loaded in the host database. 
• If a component is missing on startup, the host database does not open and the error -10509 (Impossible to open database) is generated. You can check for the presence of components when opening a database using the COMPONENT LIST command. If you want to be able to use host databases that function just as well with or without certain components, you can use the following type of code:
  
   ARRAY TEXT($arrComponents_Txt;0)
 COMPONENT LIST($arrComponents_Txt)
 If(Find in array($arrComponents_Txt;"ComponentA")>0) // Component A does not have to be present
    EXECUTE METHOD("ComponentAMethod")
 End if

Unlike other shared objects (see Shared and unshared objects), shared project methods have a “physical” existence in the database and are not simply created by code execution. 

Consequently, naming conflicts can occur when a shared project method of the component has the same name as a project method of the host database. In this case, when the code is executed in the context of the host database, it is the host database method that is called. This means that it is possible to “mask” a component method with a custom method (for example to obtain a different functionality).
Of course, when the code is executed in the component, it is the component method that is called. 

This masking will be indicated by a warning in the event of compilation of the host database. 

Note: If two components share methods having the same name, an error is generated when the host database is compiled.