IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Introduction aux plugins 4D

Date de publication : Mai 2006

Par 4D s.a. (www.4d.fr)
 

Introduction à l'outil 4D Plugin API et au développement de plugins pour 4D

Le langage 4D
Quel(s) besoin(s) pour un plug-in ?
Qu'est-ce qu'un plug-in et que peut-il faire ?
Structure d'un plug-in
Note à l'intention des utilisateurs expérimentés et des anciens utilisateurs de 4D ExtensionKit
Documentation


Le langage 4D

4ème dimension et 4D Serveur sont des gestionnaires de bases de données relationnelles cross-plateformes et graphiques qui fournissent des outils de développement puissants et flexibles dans le cadre d'un environnement simple et intuitif. Un langage de haut niveau, d'apprentissage simple, nommé Langage 4D est utilisé aussi bien pour manipuler les objets de la base (tables, sélections, enregistrements, champs…) que les objets de l'interface utilisateur (fenêtres, formulaires, barres de menus, boutons…).

Le langage 4D est un langage de programmation moderne et structuré dont les fonctionnalités sont entièrement détaillées dans le manuel de référence.

4ème Dimension peut gérer une base de données (créer, chercher, trier les enregistrements) et créer des composants d'interface graphique (fenêtres, menus, séparateurs) en utilisant un nombre de lignes de code extrêmement réduit quelle que soit la plateforme (Windows ou Mac OS). A titre de comparaison, l'implémentation des mêmes éléments en utilisant un langage natif de type C/C++ nécessiterait des milliers de lignes de code et demanderait certainement des mois au lieu de quelques minutes.


Quel(s) besoin(s) pour un plug-in ?

Bien que 4ème Dimension fournisse en standard des centaines de commandes pour manipuler les enregistrements et implémenter une interface complète, certaines utilisations spécifiques ou fonctionnalités particulières (quelques fois liées à la plateforme) peuvent être requises : certains développements, par exemple, nécessiteront l'utilisation d'OLE ou DDE sous Windows, d'autres encore d'AppleEvents sous Mac OS, ou bien d'implémenter des outils statistiques particuliers, d'accéder à certains fichiers via le réseau, ou d'intégrer une structure d'image privée.

Il est évident que couvrir l'intégralité des possibilités des environnements Windows et Mac OS par le biais unique du langage 4D aurait conduit à un produit intégrant des milliers de commandes alors que la grande majorité des utilisateurs n'en utilise que beaucoup moins. En outre, la création d'un outil aussi puissant l'aurait nécessairement rendu d'une grande complexité ce qui aurait demandé au développeur des mois d'étude avant de maîtriser l'outil.

A titre d'exemple, les modules de productivité et de connectivité de 4D tels que 4D Write, 4D Draw, 4D Open (qui sont basés sur l'architecture plug-in de 4D) fournissent une solution ouverte et élégante indépendamment des besoins spécifiques de l'utilisateur. La nature modulaire de l'environnement 4ème Dimension permet la création d'applications basiques mais pas de systèmes hautement complexes. L'architecture plug-in de 4D permet alors d'ouvrir l'environnement à tout type de technologies, d'applications ou d'utilisateurs. Les plug-ins 4D permettent de multiplier sans limite la puissance et la productivité de vos applications.


Qu'est-ce qu'un plug-in et que peut-il faire ?

Un plug-in est un bout de code (dll sous Windows ou shared lib sur Mac) que 4ème Dimension lance au démarrage. Il ajoute des fonctionnalités au produit et augmente ses capacités.

En règle générale un plug-in est censé traiter des tâches qui :

   · ne sont pas prises en charge de façon standard par 4D
     (qui sont par exemple liées à des technologies inhérentes à une plateforme spécifique…)

   · seraient extrêmement complexes à écrire en n'utilisant que 4ème Dimension

   · sont uniquement disponibles comme point d'entrée.

Par le passé, un plug-in (encore appelé " procédure externe " ou " package ") pouvait être écrit afin d'améliorer le code de l'application et de le rendre plus rapide (boucles longues, statistiques etc…) Cet usage est tombé en désuétude depuis l'apparition du Compilateur.

Un plug-in contient généralement un ensemble de routines. Il peut prendre en charge une zone externe et piloter un process externe.

Une routine de plug-in est une routine écrite dans un langage natif (C ou C++) et qui produit une action.

Une zone externe est une partie de formulaire qui peut afficher à peu près tous les types d'éléments et intéragir avec l'utilisateur dès que nécessaire.

Un process externe est un process qui tourne seul, généralement dans une boucle, accomplissant à peu près n'importe quel type de tâches. Le code du process appartient en propre au plug-in, 4ème Dimension est simplement présent pour recevoir/envoyer les évènements au process.

warning NOTE IMPORTANTE
Un plug-in peut être très simple, ne comportant qu'une routine et n'effectuant qu'une seule tâche basique, ou bien être d'une haute complexité, intégrant des centaines de routines et de zones. Il n'y a virtuellement aucune limite aux possibilités d'un plug-in, néanmoins, tout développeur doit se souvenir qu'un plug-in n'est rien d'autre qu'un bout de code, DLL ou Shared Lib, qui tourne au sein de 4ème Dimension et non l'inverse. En ce sens, il est l'hôte de 4ème Dimension, il ne s'agit pas d'une application indépendante. Il partage donc du temps CPU et de la mémoire avec 4ème dimension ainsi qu'avec les autres plug-ins, son code doit donc être le plus propre possible de façon à ne gaspiller aucune ressource. Dans les longues boucles, par exemple, un plug-in doit appeler PA_Yield() pour donner du temps au scheduler de 4ème Dimension sans quoi sa charge devient critique autant pour lui que pour la base.

Structure d'un plug-in

Afin d'être reconnu par 4ème Dimension, tout plug-in doit :

   · être une CFM Shared Lib (Mac OS 9 & Mac OS X), un MachO Bundle Package (Mac OS X) ou une DLL (Windows)

   · sous Mac OS, contenir des ressources spécifiques (cf. supra).
     [Sous Windows, un fichier (contenant les ressources) possédant
     le même nom et une extension .RSR doit se situer au même niveau que la DLL.]

   · être localisé dans le Win4DX et /ou le Mac4DX.


Les ressources d'un plug-in doivent impérativement au moins contenir :

   · Une ressource du type " 4BNX ".
     L'ID de cette ressource doit être systématiquement supérieur à 15000.

   · Une ressource du type " STR# " possédant le même ID.
     Cette ressource contient la liste des noms de routines.

   · Facultatif, mais très utile pour l'utilisateur, une ressource FON# et une ressource THM#.
     Ces ressources sont utilisées pour grouper les routines par thèmes
     dans un ou plusieurs pop-ups de l'éditeur de méthodes.


Pour toutes ces ressources il existe des templates ResEdit® ou Resorcerer®, toutefois le développeur de plug-ins préfèrera le 4D PluginWizard, une de ses fonctionnalités principales étant justement qu'il permet de construire toutes les ressources, ce qui est particulièrement utile aux utilisateurs Windows puisqu'il n'existe aucun éditeur de ressources sur cette plateforme. Toujours sous Windows, il est également possible de générer un fichier de ressources directement à partir de 4ème Dimension, néanmoins l'utilisation du PluginWizard est largement plus simple.


Note à l'intention des utilisateurs expérimentés et des anciens utilisateurs de 4D ExtensionKit

L'API 4D Plug-in a été conçue pour simplifier l'écriture des plug-ins, en l'utilisant un développeur n'écrivant qu'en C peut développer son plug-in en très peu de temps.

L'API 4D Plug-in est constituée d'une routine C qui procède au wrapping (" emballage ") des points d'entrée 4D. Le fichier source se nomme 4DPluginAPI.c . A noter : Appeler4D mais certains noms ont changé (le BlocParamètre* devient BlocMoteur*)

Les développeurs expérimentés ont probablement déjà wrappé les points d'entrée qu'ils utilisent, mais le portage du code vers cette nouvelle API peut prendre un certain temps. Les anciens plug-ins qui tournaient sous 4ème dimension 5.5 et supérieur peuvent continuer à fonctionner en notant toutefois que certains points d'entrée ne sont plus supportés.

Depuis la version 6.5 4ème dimension ne supporte plus les machines 68k. Les plug-ins nécessitent l'utilisation de doubles valeurs - REEL ne sert plus. La définition STR# des routines utilisant des réels ou des tableaux de réels doit comporter les balises " &8 " et " &Y ".


Les points d'entrée cachés

Tous les points d'entrée reconnus sont présents dans cette API. Il n'existe aucun point d'entrée caché, tous les développeurs de plug-ins utilisent les mêmes outils. 4D SA n'ouvre aucun point d'entrée public si celui-ci n'est pas supporté, s'il n'est destiné qu'à un usage interne, ou s'il est susceptible d'être modifié en cours de développement.


Modification du 4DPluginAPI.c

Les anciens utilisateurs de 4D ExtensionKit noterons qu'à certaines occasions les paramètres associés à un point d'entrée donné ne sont pas tous accessibles via l'API. Il est alors possible pour le développeur d'ajouter ses propres routines, ou de modifier certaines fonctions de l'API, mais il est préférable de le faire dans un fichier source séparé. Dans ce cas il sera plus simple d'apporter les modifications nécessaires lorsque 4D fournira de nouvelles versions de l'API.


Documentation




Valid XHTML 1.1!Valid CSS!

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.