Les classes de base de la bibliothèque
Le Delphi comprend un grand nombre de fonctions et de procédures, mais la vraie puissance de la programmation visuelle de Delphi réside dans l'énorme bibliothèque de classes l'accompagnant. La bibliothèque de classes standard de Delphi contient des centaines de classes, avec des milliers de méthodes, et elle est si grande qu'il est difficile de toute les documentés. Parmi les classes, certaines classes propose, des listes, des listes de chaînes de caractères, les collections et les flux de données. Et une grande partie des classes se trouve dans l'unité Classes.
Les classes Delphi peuvent être utilisées entièrement dans le code ou dans le concepteur visuel de formulaires. Certains d'entre eux sont des classes de composantes, apparaissant dans la palette de composantes, tandis que d'autres sont plus polyvalentes. Les termes classe et composante peuvent être utilisés presque comme des synonymes dans Delphi. Les composantes sont les éléments centraux des applications Delphi. Lorsque vous écrivez un programme, vous choisissez essentiellement un certain nombre de composantes et définissez leurs interactions. C'est tout ce qu'il y a à la programmation visuelle Delphi.
Le paquet du RTL, VCL et CLX
Jusqu'à la version 5, la bibliothèque de classes de Delphi était connue sous le nom de VCL, signifiant Visual Components Library. Puis avec Kylix, la version Delphi pour Linux, a introduit une nouvelle bibliothèque de composantes, appelée CLX (prononcé «clicks» et signifiant Component Library for X-Platform ou Cross Platform). Le Delphi 6 comprend à la fois les bibliothèques VCL et CLX. Pour les composantes visuels, les deux bibliothèques de classes sont alternatives l'une à l'autre. Cependant, les classes principales et les parties base de données et Internet des deux bibliothèques sont essentiellement partagées.
La VCL était considérée comme une seule grande bibliothèque, bien que les programmeurs se référaient à différentes parties de celle-ci (composantes, contrôles, composantes non visuels, ensembles de données, contrôles orientés données, composantes Internet,...). Le CLX introduit une distinction en quatre parties : BaseCLX, VisualCLX, DataCLX et NetCLX. Ce n'est que dans VisualCLX que la bibliothèque utilise une approche totalement différente entre les deux plates-formes, le reste du code étant intrinsèquement portable sous Linux.
Dans Delphi 6, cette distinction est soulignée par le fait que les composantes non visuels et les classes de base de la bibliothèque font partie du nouveau paquet RTL, étant utilisé à la fois par VCL et CLX. De plus, l'utilisation de ce paquet dans des applications non visuelles (par exemple, des programmes de serveur Web) vous permet de réduire considérablement la taille des fichiers à déployer et à charger en mémoire.
Sections traditionnelles de VCL
Les programmeurs Delphi utilisent pour faire référence à différentes sections de VCL avec des noms initialement suggérés pour Delphi dans sa documentation, et des noms étant devenus communs par la suite pour différents groupes de composantes. Techniquement, les composantes sont des sous-classes de la classe TComponent, étant l'une des classes racine de la hiérarchie, comme vous pouvez le voir dans la figure suivante :
En fait, la classe TComponent hérite de la classe TPersistent. Outre les composantes, la bibliothèque comprend des classes héritant directement de TObject et de TPersistent. Ces classes non-composantes sont souvent utilisées pour les valeurs de propriétés ou comme classes utilitaires utilisées dans le code; n'héritant pas de TComponent, ces classes ne peuvent pas être utilisées directement en programmation visuelle.
Pour être plus précis, les classes non-composantes ne peuvent pas être rendues disponibles dans la palette de composantes et ne peuvent pas être déposées directement dans un formulaire, mais elles peuvent être gérées visuellement avec l'inspecteur d'objets, en tant que sous-propriétés d'autres propriétés ou éléments de collections de différents types. Ainsi, même les classes sans composante sont souvent facilement utilisées lors de l'interaction avec le Form Designer.
Les classes de composantes peuvent être divisées en deux groupes principaux: les contrôles et les composantes non visuels. Les contrôles regroupe toutes les classes descendant de TControl.
Les contrôles ont une position et une taille à l'écran et s'affichent dans le formulaire au moment de la conception dans la même position qu'ils occuperont au moment de l'exécution. Les contrôles ont deux sous-spécifications différentes, basées sur des fenêtres ou graphiques.
Les composantes non visuels sont tous les composantes n'étant pas des contrôles - toutes les classes descendante de TComponent mais pas de TControl. Au moment de la conception, une composante non visuel apparaît sur le formulaire sous la forme d'une icône (éventuellement avec une légende en dessous). Au moment de l'exécution, certains de ces composantes peuvent être visibles (par exemple, les boîtes de dialogue standard) et d'autres sont toujours invisibles (par exemple, la composante de table de base de données).
Vous pouvez simplement déplacer le curseur de la souris sur un contrôle ou une composante dans le Form Designer pour voir un Tooltip (info-bulle) avec son nom et son type de classe. Vous pouvez également utiliser une option d'environnement, afficher les légendes des composantes, pour voir le nom d'une composante non visuel juste sous son icône.
La structure de CLX
C'est la subdivision traditionnelle de VCL, étant très courante pour les programmeurs Delphi. Même avec l'introduction de CLX et de nouveaux schémas de dénomination, les noms traditionnels survivront probablement et fusionneront dans le jargon des programmeurs Delphi. Le Delphi fait référence à différentes parties de la bibliothèque CLX en utilisant une terminologie sous Linux et une structure de dénomination légèrement différente (et moins claire) dans Delphi. C'est la subdivision de la bibliothèque compatible Linux :
| Nom | Description |
|---|---|
| BaseCLX | Cette partie forme le noyau de la bibliothèque de classes, les classes les plus élevées (telles que TComponent) et plusieurs classes d'utilitaires générales (y compris les listes, les conteneurs, les collections et les flux de données). Par rapport aux classes correspondantes de VCL, le BaseCLX est en grande partie inchangé et est hautement portable entre les plates-formes Windows et Linux. |
| VisualCLX | Cette partie contient la collection de composantes visuels, généralement indiqués comme des contrôles. C'est la partie de la bibliothèque étant la plus étroitement liée au système d'exploitation : VisualCLX est mise en oeuvre au-dessus de la bibliothèque Qt, disponible à la fois sous Windows et sous Linux. L'utilisation de VisualCLX permet une portabilité complète de la partie visuelle de votre application entre Delphi sous Windows et Kylix sous Linux. Cependant, la plupart des composantes VisualCLX ont des contrôles VCL correspondants, de sorte que vous pouvez également déplacer facilement votre code d'une bibliothèque à l'autre. |
| DataCLX | Cette partie comprend tous les composantes liés à la base de données de la bibliothèque. En fait, DataCLX est le frontal du nouveau moteur de base de données dbExpress inclus à partir de Delphi 6 et Kylix. Le Delphi inclut également le frontal BDE traditionnel, dbGo et IBX (InterBase Express). Si nous pouvons considérer tous ces composantes comme faisant partie de DataCLX, seuls le frontal dbExpress et IBX sont portables entre Windows et Linux. Le DataCLX comprend également les composantes ClientDataSet, désormais indiqué comme MyBase, et d'autres classes associées. |
| NetCLX | Cette partie permet d'inclure les composantes liés à Internet, du cadre d'application WebBroker, aux composantes du producteur HTML, d'Indy (Internet Direct) à Internet Express, du Site Express au support XML. Cette partie de la bibliothèque est, encore une fois, hautement portable entre Windows et Linux. |
Sections spécifiques à la VCL de la bibliothèque
Les zones précédentes de la bibliothèque sont disponibles, sur Delphi et Kylix. Dans Delphi, cependant, il existe d'autres sections de VCL, qui pour une raison ou une autre sont spécifiques à Windows uniquement :
- Le cadre d'application DAX (Delphi ActiveX) prend en charge les technologies COM, OLE Automation, ActiveX et d'autres technologies COM.
- Les composantes Decision Cube fournissent une prise en charge OLAP mais sont liés au BDE et n'ont pas été mis à jour récemment.
Enfin, l'installation par défaut de Delphi inclut certaines composantes tiers, tels que TeeChart pour les graphiques d'entreprise et QuickReport pour les rapports.
La classe TPersistent
La première classe de base de la bibliothèque Delphi est la classe TPersistent, ce qui est assez étrange : elle a très peu de code et presque pas d'utilisation directe, mais elle fournit une base pour toute l'idée de la programmation visuelle. Voici la définition de la classe contenu dans l'unité Classes :
- {$M+}
- Type
- TPersistent=Class(TObject)
- Private
- Procedure AssignError(Source:TPersistent);
- Protected
- Procedure AssignTo(Dest:TPersistent);Virtual;
- Procedure DefineProperties(Filer:TFiler); Virtual;
- Function GetOwner:TPersistent; Dynamic;
- Public Destructor Destroy; Override;
- Procedure Assign>(Source:TPersistent); Virtual;
- Function GetNamePath:string; Dynamic;
- End;
Comme son nom l'indique, cette classe gère la persistance, c'est-à-dire l'enregistrement de la valeur d'un objet dans un fichier à utiliser ultérieurement pour recréer l'objet dans le même état et avec les mêmes données. La persistance est un élément clef de la programmation visuelle. En fait au moment de la conception dans Delphi, vous manipulez des objets réels, étant enregistrés dans des fichiers DFM et recréés au moment de l'exécution lorsque le conteneur de composante spécifique - formulaire ou module de données - est créé. La prise en charge du flux de données, cependant, n'est pas intégrée dans la classe TPersistent mais est fournie par d'autres classes, ciblant TPersistent et ses descendants. En d'autres termes, vous pouvez persister avec les objets Delphi par défaut de diffusion uniquement des classes héritant de TPersistent. Une des raisons de ce comportement réside dans le fait que la classe est compilée avec une option spéciale activée, {$M+}. Cet indicateur active la génération d'informations RTTI étendues pour la partie publiée de la classe.
Le système de diffusion en continu de Delphi, en fait, n'essaie pas de sauvegarder les données en mémoire d'un objet, ce qui serait complexe à cause des nombreux pointeurs vers d'autres emplacements de mémoire, totalement dénués de sens lorsque l'objet serait rechargé. Au lieu de cela, Delphi enregistre les objets en listant la valeur de toutes les propriétés marquées d'un mot clef spécial, publié. Lorsqu'une propriété fait référence à un autre objet, Delphi enregistre le nom de l'objet ou de l'objet entier (avec le même mécanisme) en fonction de son type et de sa relation avec l'objet principal. Parmi les méthodes de la classe TPersistent, la seule que vous utiliserez généralement est la procédure Assign, pouvant être utilisée pour copier la valeur réelle d'un objet. Dans la bibliothèque, cette méthode est mise en oeuvre par de nombreuses classes non-composantes mais par très peu de composantes. En fait, la plupart des sous-classes réimplémentent la méthode AssignTo protégée virtuelle, appelée par la mis en oeuvre par défaut d'Assign. D'autres méthodes incluent DefineProperties, utilisée pour personnaliser le système de diffusion en continu et ajouter des informations supplémentaires (pseudo-propriétés), et les méthodes GetOwner et GetNamePath utilisées par les collections et autres classes spéciales pour s'identifier auprès de l'inspecteur d'objets.
Le mot-clef published
En plus des directives d'accès public, protected et private, vous pouvez utiliser une quatrième, appelée published. Pour tout champ, propriété ou méthode publié, le compilateur génère des informations RTTI étendues, de sorte que l'environnement d'exécution de Delphi ou un programme puisse interroger une classe pour son interface publiée. Par exemple, chaque composante Delphi a une interface publiée étant utilisée par l'EDI, en particulier l'inspecteur d'objets. Une utilisation régulière des champs publiés est importante lorsque vous écrivez des composantes. Habituellement, la partie publiée d'une composante ne contient aucun champ ou méthode mais des propriétés et des événements.
Lorsque Delphi génère un formulaire ou un module de données, il place les définitions de ses composantes et méthodes (les gestionnaires d'événements) dans la première partie de sa définition, avant les mots-clefs public et private. Ces champs et méthodes de la partie initiale de la classe sont publiés. La valeur par défaut est publiée lorsqu'aucun mot clef spécial n'est ajouté avant un élément d'une classe de composantes.
Pour être plus précis, published est le mot-clef par défaut uniquement si la classe a été compilée avec la directive du compilateur $M+ ou est issue d'une classe compilée avec $M+. Comme cette directive est utilisée dans la classe TPersistent, la plupart des classes de VCL et toutes les classes de composantes sont publiées par défaut. Cependant, les classes non-composantes dans Delphi (telles que TStream et TList) sont compilées avec $M- et par défaut à la visibilité publique.
Les méthodes attribuées à tout événement doivent être des méthodes publiées et les champs correspondant à vos composantes dans le formulaire doivent être publiés pour être automatiquement connectés aux objets décrits dans le fichier DFM et créés avec le formulaire.