4D v14.3

Installation et compatibilité des composants

Accueil

 
4D v14.3
Installation et compatibilité des composants

Installation et compatibilité des composants  


 

Pour installer un composant dans une base de données 4D, il suffit de copier le fichier de structure de la base matrice dans un dossier Components accessible pour la base hôte. Le dossier Components peut être placé à deux endroits :

  • au niveau de l’application 4D exécutable : dans ce cas, les composants sont disponibles dans toutes les bases de données ouvertes par cette application.
  • au même niveau que le fichier de structure de la base : dans ce cas, les composants sont disponibles dans la base uniquement.

Pour plus d'informations sur ce point, reportez-vous au paragraphe Emplacements pour les dossiers PlugIns et Components.

4D recherchera dans le dossier Components les bases matrices du type .4db (base matrice interprétée), .4dc (base matrice compilée) ou .4dbase (base matrice de type paquet). Les autres éléments, notamment les fichiers de données ou les fichiers de structure utilisateur (.4DA), sont ignorés. Vous pouvez utiliser des alias ou des raccourcis vers ces bases matrices. Cette possibilité est particulièrement utile en phase de développement du composant car toute modification effectuée dans la base matrice est immédiatement reportée dans toutes les bases hôtes. 

Le dossier Components peut contenir tout fichier ou dossier personnalisé nécessaire au fonctionnement du composant (xliff, images...). En revanche, il ne peut pas contenir de plug-ins ou de sous-dossiers Components. Si ces éléments sont présents, ils sont ignorés par 4D. Les plug-ins utilisés par les composants doivent être installés dans la base hôte ou dans 4D. 

Une base hôte exécutée en mode interprété peut utiliser indifféremment des composants interprétés ou compilés, en mode Unicode ou non. Il est possible d’installer des composants interprétés et compilés dans la même base hôte. Toutefois, si plusieurs composants compilés sont présents, ils doivent être exécutés dans le même mode Unicode.

Une base hôte exécutée en mode compilé ne peut pas utiliser de composant interprété. Dans ce cas, seuls des composants compilés peuvent être employés. De même, le mode Unicode doit être identique pour la base hôte et les composants. 

Le tableau suivant résume les possibilités d’usage des composants :

Composants interprétésComposants compilés
UnicodeNon UnicodeUnicodeNon Unicode
Base hôte interprétéeUnicodeXXX (*)X (*)
Non UnicodeXXX (*)X (*)
Base hôte compiléeUnicode--X-
Non Unicode---X

(*) Si plusieurs composants compilés sont installés, ils doivent fonctionner dans le même mode Unicode. 

Notes :

  • Une base hôte interprétée contenant des composants interprétés peut être compilée si elle ne fait pas appel à des méthodes du composant interprété. Dans le cas contraire, une boîte de dialogue d’alerte apparaît lorsque vous lancez la compilation et l’opération est impossible.
  • De façon générale, une méthode interprétée peut appeler une méthode compilée et non l’inverse, hormis via l’utilisation des commandes EXECUTER METHODE et EXECUTER FORMULE.

Pour plus d’informations sur les échanges inter-composants et base hôte-composants, reportez-vous à la section Interaction entre les composants et les bases hôtes.

Un composant interprété développé sous Mac OS peut être installé dans un environnement Windows et inversement.
En revanche, la plate-forme d’exécution des composants compilés doit correspondre à la plate-forme de compilation, ou bien ils doivent avoir été compilés pour les deux plates-formes.

Les composants installés dans la base serveur sont automatiquement transférés sur les postes clients via un mécanisme proche de celui des plug-ins. 

Il est déconseillé de modifier un composant en client/serveur car les modifications seront stockées en local, le composant ne sera pas mis à jour sur le poste serveur.

Les composants sont chargés à l’ouverture de la base hôte.

  • Si un composant contient du code compilé et du code interprété qui ne correspondent pas, un message d’erreur est affiché et le composant n’est pas chargé dans la base hôte. 
  • Si un composant est manquant au démarrage, la base hôte ne s’ouvre pas et l'erreur -10509 (Impossible d'ouvrir la base de données) est générée.
    Il est possible de vérifier la présence de composants à l'ouverture de la base à l’aide de la commande LISTE COMPOSANTS. Si vous souhaitez pouvoir utiliser des bases hôtes fonctionnant aussi bien avec que sans certains composants, vous pouvez utiliser le type de code suivant :
     TABLEAU TEXTE($tTxt_Components;0)
     LISTE COMPOSANTS($tTxt_Components)
     Si(Chercher dans tableau($tTxt_Components;"ComposantA")>0)  // le composant A peut ne pas être présent
        EXECUTER METHODE("LaMethodeDuComposantA")
     Fin de si

Un composant peut exécuter automatiquement du code 4D lors de l’ouverture et de la fermeture de la base hôte, afin par exemple de charger et de sauvegarder des préférences ou des états utilisateurs liés à l’exploitation de la base hôte. 

L'exécution de code d'initialisation ou de fermeture s'effectue à l'aide de la Méthode base Sur événement base hôte. Pour plus d'informations, reportez-vous à la description de cette méthode base dans le manuel Langage de 4D.

A noter que pour des raisons de sécurité, l’exécution de cette méthode base doit être autorisée explicitement dans la base hôte pour qu’elle puisse être appelée. Pour cela, vous devez cocher l'option Exécuter la méthode "Sur événement base hôte" des composants dans la Page Sécurité des Propriétés de la base :


A la différence des autres objets partagés (cf. paragraphe Objets partagés et objets non partagés), les méthodes projet partagées ont une existence “physique” dans la base, elles ne sont pas créées par l’exécution de code. 

Par conséquent, un conflit de nom peut se produire lorsqu’une méthode projet partagée du composant a le même nom qu’une méthode projet de la base hôte. Dans ce cas, lorsque du code est exécuté dans le contexte de la base hôte, c’est la méthode de la base hôte qui est appelée. Ce principe permet de “masquer” une méthode du composant avec une méthode personnalisée (par exemple pour obtenir une fonctionnalité différente).
Bien entendu, lorsque le code est exécuté dans le contexte du composant, c’est la méthode du composant qui est appelée. 

Un masquage est signalé par un warning en cas de compilation de la base hôte. 

Note : Si deux composants partagent des méthodes du même nom, une erreur est générée au moment de la compilation de la base hôte

 
PROPRIÉTÉS 

Produit : 4D
Thème : Développer et installer des composants 4D
Nom intl. : Component installation and compatibility

 
UTILISATION DE L'ARTICLE

4D - Mode Développement ( 4D v14 R2)
4D - Mode Développement ( 4D v14 R3)
4D - Mode Développement ( 4D v14.3)
4D - Mode Développement ( 4D v14 R4)

Hérité de : Installation et compatibilité des composants ( 4D v13.4)