Guide Pascal et Delphi

Passons à la vitesse supérieure. Nous allons utiliser une fonctionnalité fort appréciable de la classe TStringList : la méthode Sort. Cette méthode applique un tri alphabétique sur les chaînes présentes dans la liste maintenue par l'objet dont on appelle la méthode Sort. Concrètement, les chaînes sont simplement réorganisées de sorte que la première dans l'ordre alphabétique ait l'indice 0 dans la propriété tableau par défaut de l'objet. Pour illustrer cela, nous allons confectionner une procédure (toujours déclenchée par un clic sur un bouton, pour faire dans l'originalité) qui demande de saisir des chaînes. La procédure demandera des chaînes jusqu'à ce que l'on clique sur "Annuler" et non "OK". La procédure affichera alors le nombre de chaînes entrées dans la liste, puis les chaînes dans l'ordre alphabétique.

Si vous voulez réaliser cela comme un exercice, c'est le moment d'arrèter de lire et de vous mettre à chercher : ce qui suit réalise pas à pas ce qui vient d'être proposé ci-dessus.

La première chose à faire est de bien discerner les étapes à programmer :

1. initialisation de l'objet qui gérera la liste
2. une boucle demandant un nombre à priori inconnu de chaînes
3. l'affichage du nombre de chaînes
4. le tri alphabétique de la liste
5. l'affichage d'un nombre connu de chaînes
6. destruction de l'objet

La première étape nécessite une boucle : chaque itération lira une chaîne et la boucle s'arrètera lorsque la condition "la chaine entrée est la chaîne vide" est réalisée. Le problème est qu'une boucle for est inadaptée puisque le nombre de chaînes que l'utilisateur désire rentrer est inconnu et puisque nous ne souhaitons pas fixer ce nombre. Restent deux boucles possibles : une boucle while ou une boucle repeat. Pour savoir laquelle utiliser, la question est toujours la même : le contenu de la boucle sera-t-il à exécuter au moins une fois ? La réponse dépend de ce que nous allons effectuer à chaque itération, c'est pour cela qu'il est toujours nécessaire de réfléchir à un programme d'abord sur papier avant de se lancer dans l'écriture du code.

Nous allons utiliser la fonction InputQuery pour lire les chaînes à rentrer dans la liste. Cette fonction renvoie un résultat booléen qui peut être utilisé indifférement dans une condition d'arrèt ou de poursuite (selon le type de boucle choisie). Etant donné que la fonction renvoie true si l'utilisateur valide sa saisie, on peut utiliser la boucle suivante :

while InputQuery({...}) do
  {...}

Lors de l'entrée dans la boucle, InputQuery sera exécutée. Son résultat sera utilisé comme condition d'arrèt : si l'utilisateur annule, on n'effectue pas d'itération, s'il valide, on effectue une itération et on refait une demande de chaîne, et ainsi de suite. Nous aurions pu écrire les choses de façon plus compréhensible mais plus longue en utilisant une variable booléenne :

Cont := True;
while Cont do
  begin
    Cont := InputQuery({...});
    ...
  end;

ou même comme cela :

repeat
  Cont := InputQuery({...});
  ...
until not Cont;

mais ces deux méthodes auraient introduit des difficultés supplémentaires car il aurait fallu tester la valeur de Cont avant d'effectuer un quelconque traitement, ce qui nous aurait obligé à utiliser une boucle if. La méthode choisie est plus propre et est plus proche d'un raisonnement logique du genre "tant que l'utilisateur valide sa saisie, on traite sa saisie".

Passons au contenu de la boucle, c'est-à-dire à ce qui est éxécuté à chaque itération : La chaîne entrée par l'utilisateur est tout simplement ajoutée à la liste. Il faudra également penser à vider la chaîne lue car rappelez-vous que cette chaîne est affichée dans la boite de dialogue de saisie. Il faudra aussi la vider avant la première itération car la première lecture s'effectuera avant le premier « vidage ». Voici donc la première partie de la procédure, qui inclue également la construction et la destruction de l'objet de classe TStringList puisque ce dernier est utilisé dans la boucle while :

procedure TForm1.Button1Click(Sender: TObject);
var
  StrLst: TStringList;
  STemp: String;
begin
  StrLst := TStringList.Create;
  STemp := '';
  while InputQuery('Entrez une chaîne', 'Chaine à ajouter à la liste :', STemp) do
    begin
      StrLst.Add(STemp);
      STemp := '';
    end;
  StrLst.destroy;
end;

Ce code permet de lire autant de chaînes que l'on veut et de les stocker dans une liste de chaînes. La deuxième étape qui consiste à afficher le nombre de chaînes entrées par l'utilisateur est la plus simple de ce que nous avons à faire :

ShowMessage('Vous avez entré ' + IntToStr(StrLst.Count) + ' chaînes');

Il nous faut ensuite trier la liste. Pour cela, il suffit d'appeler la méthode Sort de l'objet StrLst :

StrLst.Sort;

Enfin, il nous faut afficher les chaînes. Ici, on ne sait pas combien il y en a, mais ce nombre est contenu dans la propriété Count de l'objet. On utilise donc une boucle for avec une variable allant de 0 à StrLst.Count - 1. L'affichage passe par un simple appel à ShowMessage. Pour donner du piquant à cet affichage, on donne à l'utilisateur un affichage du style "chaîne n° x sur y : chaîne" (indx + 1 est utilisé pour donner le numéro actuel, en partant de 1 au lieu de 0, et StrLst.Count est utilisé pour donner le nombre de chaînes) :

for indx := 0 to StrLst.Count - 1 do
  ShowMessage('Chaîne n° ' + IntToStr(indx + 1) + ' sur ' +
    IntToStr(StrLst.Count) + ' : ' + StrLst[indx]);

Voici enfin le code complet de la procédure que nous avons créée. Vous constaterez qu'elle est très courte, mais qu'elle fait intervenir nombre de notions importantes non seulement concernant les objets, mais aussi concernant les boucles.

procedure TForm1.Button1Click(Sender: TObject);
var
  StrLst: TStringList;
  STemp: String;
  indx: integer;
begin
  StrLst := TStringList.Create;
  STemp := '';
  while InputQuery('Entrez une chaîne', 'Chaine à ajouter à la liste :', STemp) do
    begin
      StrLst.Add(STemp);
      STemp := '';
    end;
  ShowMessage('Vous avez entré ' + IntToStr(StrLst.Count) + ' chaînes');
  StrLst.Sort;
  for indx := 0 to StrLst.Count - 1 do
    ShowMessage('Chaîne n° ' + IntToStr(indx + 1) + ' sur ' +
      IntToStr(StrLst.Count) + ' : ' + StrLst[indx]);
  StrLst.destroy;
end;

Les objets sont des structures pour la plupart très complexes dans le sens où ils possèdent un nombre important de méthodes, de variables et de propriétés. Mettez-vous un instant à la place d'un programmeur chevronné et imaginez par exemple tout ce qu'il faut pour faire fonctionner un simple bouton : il faut entre autres le dessiner, réagir au clavier, à la souris, s'adapter en fonction des propriétés. C'est une tâche, croyez-moi sur parole, qui nécessite un volume impressionnant de code Pascal Objet. Prenons un autre composant, par exemple une zone d'édition : elle réagit également au clavier et à la souris. Ne serait-il pas intéressant de pouvoir « regrouper » la gestion du clavier et de la souris à un seul endroit pour éviter de la refaire pour chaque composant (pensez qu'il existe des milliers de composants).

De tels besoins de regroupement, il en existe énormément. Pour cela, il existe la notion de hiérarchie parmi les classes. Cette hiérarchisation permet de regrouper dans une classe « parent » un certain nombre de propriétés, de méthodes et de variables. Les classes qui auront besoin d'avoir accès à ces fonctionnalités devront simplement « descendre » de cette classe, c'est-à-dire être une classe « descendante » de cette classe « parent ».

Le principe de la hiérarchie des classes est en effet basé sur la relation parent-enfant ou plus exactement parent-descendant. Chaque classe possède, contrairement à ce que l'on peut voir d'insolite dans les relations parent-descendant humaines, une seule et unique classe parente directe. Une classe peut avoir un nombre illimité de descendants. Lorsqu'une classe descend d'une autre classe, la première possède absolument tout ce qui est défini par la seconde : c'est l'héritage. La classe « descendante » est plus puissante que la classe « parente » dans le sens où de nouvelles méthodes, variables et propriétés sont généralement ajoutées ou modifiées.

Une telle hiérarchie impose l'existence d'un unique ancètre ultime qui n'a pas de parent : c'est la classe « TObject » (qui possède un nom quelque peu embrouillant). De cette classe descendent TOUTES les classes existantes sous Delphi, et ceci plus ou moins directement (toutes les classes ne sont pas des descendantes directes de TObject mais sont souvent des descendantes de descendantes de... de « TObject ». Cette dernière définit les mécanismes de base du fonctionnement d'un objet. Tous les objets sous Delphi sont d'une classe descendante de TObject, et possèdent donc tout ce que définit TObject, à savoir le minimum.

La classe « TObject » ne vous est pas inconnue car elle est mentionnée dans toutes les procédures associées à des événements. Voici un extrait de code qui devrait vous aider à y voir plus clair :

procedure TfmPrinc.Button1Click(Sender: TObject);
begin

end;

Dans l'extrait de code ci-dessus, la seule partie qui restait énigmatique, à savoir « Sender: TObject », est simplement la déclaration d'un paramètre de type TObject, c'est-à-dire que Sender est un objet de classe TObject.

Prenons une classe que vous connaissez : « TStringList ». Cette classe descend de « TObject », mais pas directement. Elle a pour parent la classe « TStrings ». La classe « TStrings » peut avoir un nombre illimité de classes descendantes, et a entre autre « TStringList » comme descendante directe. « TStrings » est moins puissante que « TStringList » car cette dernière, en plus de l'héritage complet de ce que contient « TStrings », contient bien d'autres choses. La classe « TStrings » a pour parent la classe « TPersistent ». Cette classe, qui est encore moins perfectionnée que « TStrings », a enfin pour parent la classe « TObject », ce qui termine l' « arbre généalogique » de TStringList. Voici un schémas qui résume cette descendance :

Nous avons déjà plusieurs fois dit au cours de ce chapitre que les composants sont des objets. Il est maintenant temps de parler de la classe TComponent. Cette classe est elle aussi descendante de TObject. Voici son « arbre généalogique, pour curiosité :

L'intérêt de cette classe, c'est qu'elle est à l'origine de la définition des composants. Un composant est en fait par définition un objet dont la classe descend de TComponent. TComponent définit les caractéristiques de base nécessaire à tout composant. Tous les composants que vous connaissez, et tous les autres, sont d'une classe descendante de TComponent.

Prenons la classe TButton qui permet de créer les composants boutons bien connus. Cette classe est bien un descendant de TComponent, mais la descendance est indirecte puisqu'il y a des classes intermédiaires qui ajoutent chacune un grand nombre de fonctionnalités. Voici l' « arbre généalogique » de TButton :

Comme vous pouvez le constater, TButton possède une longue ascendance pour atteindre TObject. C'est en quelque sorte le reflet de la complexité du composant : on ne se rend pas compte lorsqu'on place un bouton sur une fiche que c'est une petite usine à gaz qu'on met en fonctionnement. Puisque nous en sommes à parler des fiches, la classe TForm qui permet de définir des fiches est également une descendante de TComponent. Son arbre généalogique a été inclus ci-dessous, et les composants TStringList, TButton ont été inclus dans le schéma pour vous montrer qu'on obtient visuellement une sorte de hiérarchie entre les classes lorsqu'on en prend un nombre suffisant :

Si j'insiste autant sur cette notion de hiérarchie entre les classes, c'est non seulement car sa compréhension est indispensable pour tout bon programmeur, mais surtout pour en venir à un certain bloc de code que vous connaissez pour l'avoir déjà vu un grand nombre de fois (il apparaît lorsque vous créez un projet vierge ou une nouvelle fiche, avec de petites variantes) :

type
  TForm1 = class(TForm)
  private
    { Private declarations }
  public
    { Public declarations }
  end;

La ligne qui nous intéresse plus particulièrement ici est : « TForm1 = class(TForm) ». Cette ligne, nous l'avons déjà expliqué, définit un nouveau type "TForm1". Ce qui est nouveau et que vous pouvez désormais comprendre, c'est que cette ligne déclare "TForm1" comme une classe (mot réservé class) descendante de la classe "TForm". Une relation de type « parent - descendant » existe entre TForm1 et TForm. Voici la relation entre les deux, exprimée comme un morceau d' « arbre généalogique » (l'ascendance de TForm a été omise pour gagner un peu de place) :

La classe "TForm1" descendante de "TForm" peut alors définir de nouveaux éléments : méthodes, variables, propriétés, ... Les éléments ajoutés sont listés d'une manière spécifique que nous ne décrirons pas en détail ici, entre les mots réservés class et end.

Faites l'expérience d'ajouter un bouton et de générer la procédure associée à son événement OnClick. L'extrait de code devient :

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

Vous voyez que deux lignes ont fait leur apparition, l'une décrivant un élément Button1 de type TButton et l'autre une procédure. Ces deux éléments sont deux nouveaux éléments de la classe TForm1 : ils ne sont pas présents dans la classe TForm. La classe TForm1 a été améliorée par rapport à TForm en ce sens qu'elle possède deux nouveaux éléments. Le premier est une variable interne (on nommera plutôt champ une variable interne à une classe) et le second une méthode de la classe TForm1. Tout objet de cette classe possède ces deux éléments, en particulier l'objet Form1 déclaré de classe TForm1.

Vous voyez peut-être ici toute la puissance de la hiérarchie des classes de Delphi : pour créer une fiche comportant un bouton, il a suffit d'exploiter la classe TForm qui permet d'utiliser une fiche vierge de base, de créer une classe descendante de TForm, et d'y ajouter ce qu'on voulait en plus sur la fiche, ici un composant Button1 de classe TButton. Sans cette hiérarchie des classes, il aurait fallu beaucoup plus de code car il aurait fallu passer par des appels à Windows et par des procédures relativement complexes pour un débutant.

La partie située entre class et end est la déclaration de la classe TForm1. Dans ce morceau de code, on place les déclarations des éléments de la classe. Les variables se déclarent comme dans un bloc var, les méthodes se déclarent comme dans une unité, à savoir qu'on inclut la ligne de déclaration que l'on placerait habituellement dans l'interface de l'unité. Ce bloc de code qui contient la déclaration de la classe "TForm1" ne déclare bien entendu que ce qui est ajouté à TForm1 en plus de ce que contient TForm. Ce bloc est divisé en plusieurs parties, que nous allons étudier avant de pouvoir nous-mêmes ajouter des éléments aux classes.

Jusqu'ici, nous avons appris qu'une classe contenait des méthodes, des champs (nous allons passez progressivement de la dénomination de variable à celle de champ, qui est préférable dans le cadre des classes), des propriétés, et encore d'autres choses. Tout comme les classes ne sont pas un ensemble désorganisé, il existe à l'intérieur d'une classe un certain classement, dont le principe n'a rien à voir avec la notion de hiérarchie des classes, et qui est également plus simple à comprendre.

Une classe comporte en pratique un maximum de cinq sections. Chaque élément défini par une classe est classé dans l'une de ces sections. Parmi ces cinq sections, nous allons en étudier seulement trois ici. Les sections sont visibles au niveau du code source car délimitées par des mots réservés à cet effet. Le début d'une section est généralement donné par un mot réservé, sa fin est donnée par le début d'une autre section ou la fin de la définition de la classe (par le mot réservé end). La première section que l'on rencontre dans une classe est située avant toutes les autres : elle est délimitée au début par class(...) et est terminée comme indiqué ci-dessus par le début d'une autre section ou la fin de la déclaration de la classe. Les deux autres sections sont débutées par les mots réservés private ou public. Voici l'extrait de code utilisé dans le paragraphe précédent, commenté pour vous montrer le début et la fin des trois sections :

type
  TfmPrinc = class(TForm)
    { section débutée après class(...) }
    { section terminée par le début de la section "private" }
  private
    { section private débutée par le mot réservé "private" }
    { Private declarations }
    { section private terminée par le début de la section "public" }
  public
    { section public débutée par le mot réservé "public" }
    { Public declarations }
    { section public terminée par la fin de la classe (end) }
  end;

Le but de ces sections est de spécifier la visibilité des éléments qu'elles contiennent vis-à-vis de l'extérieur de la classe. La première section est réservée exclusivement à Delphi. Vous n'avez pas le droit d'y écrire quoi que ce soit vous-même. La section suivante débutée par le mot réservé private est nommée « section privée » de la classe : tout ce qui y est écrit est innaccessible depuis l'extérieur, il n'y a que depuis d'autres éléments de la classe que vous pouvez y accèder. Cette section est idéale pour mettre des champs dont la valeur ne doit pas être modifiée depuis l'extérieur (je vais expliquer tout cela plus en détail dans le paragraphe suivant). La troisième et dernière section est nommée « section publique » : tout ce qui y est écrit est accessible depuis l'extérieur. Lorsque par exemple vous pouvez utiliser une méthode d'un objet ou d'un composant, c'est que cette méthode est dans la section publique de la classe de ce composant. En ce qui concerne la section réservée à Delphi, tous les éléments qui y sont déclarés sont visibles comme s'ils étaient déclarés dans la section publique.

Pour bien comprendre l'intérêt de telles sections, considèrons un objet simulant une salle d'opération. La section publique comprendrait par exemple une méthode pour lancer telle opération. Par contre, la méthode destinée à manier le scalpel serait assurément privée, car une mauvaise utilisation aurait des conséquences fâcheuses. De même, un champ "Patient" serait public, pour que vous puissiez décider qui va subir l'opération, mais un champ "température" fixant la température de la salle d'opération serait privé, car c'est un paramètre sensible qui doit être manipulé avec précaution.

Nous en savons assez pour commencer à ajouter des éléments aux classes. Pour le moment, nous allons ajouter ces éléments dans la classe TForm1 descendante de TForm. L'intérêt d'ajouter des éléments à ces classes ne vous apparaît peut-être pas encore, mais cela viendra avec l'expérience.

Tout d'abord, le nom de cette classe (TForm1) est décidé dans l'inspecteur d'objets : changez le nom de la fiche (propriété "name") en "fmPrinc" et observez le changement : la classe s'appelle désormais "TfmPrinc". Ce nom est fabriqué en préfixant un "T" au nom que vous choisissez pour la fiche. L'objet qui est alors déclaré de classe TfmPrinc est alors bien "fmPrinc", nom que vous avez choisi pour la fiche et qui est en fait, comme vous le saviez déjà, le nom de la variable qui stocke la fiche :

type
  TfmPrinc = class(TForm)
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  fmPrinc: TfmPrinc;

Nous allons maintenant ajouter un champ nommé fTest de type Integer (le préfixe f ou F est souvent employé pour préfixer les identificateurs qui servent à nommer les champs des classes) à la classe TfmPrinc. Nous allons en outre faire cet ajout dans la section publique de la classe. Pour cela, complètez sous Delphi votre code en prenant comme modèle l'extrait suivant où la modification a été effectuée :

type
  TfmPrinc = class(TForm)
  private
    { Private declarations }
  public
    { Public declarations }
    fTest: Integer;
  end;

var
  fmPrinc: TfmPrinc;

La classe TfmPrinc déclarant un champ fTest de type Integer, tous les objets de cette classe et des éventuelles classes descendantes de TfmPrinc contiendront une variable fTest. C'est le même principe avec les éléments rajoutés par Delphi tels les composants ou les méthodes associées aux événements. Ces éléments sont en fait déclarés dans la classe et sont donc accessibles dans l'objet qui est déclaré de cette classe. Posez donc un bouton nommé "btAction" sur la fiche et générez la procédure (i.e. la méthode) associée à son événement OnClick. La déclaration de la classe TfmPrinc est alors :

TfmPrinc = class(TForm)
  btAction: TButton;
  procedure btActionClick(Sender: TObject);
private
  { Private declarations }
public
  { Public declarations }
  fTest: Integer;
end;

Vous remarquez que la méthode btActionClick et le champ btAction sont déclarés avant les sections privées et publiques, dans l'espace réservé à Delphi. Ces deux éléments, ainsi que le champ fTest, font partie de la classe TfmPrinc. De ce fait, la méthode btActionClick a accès non seulement à btAction puisque ce champ est public (il est déclaré dans la section réservée à Delphi, qui est analogue à la section publique en terme de visibilité), mais également au champ fTest puisque la méthode est à l'intérieur de la classe. Nous allons modifier la valeur du champ fTest et afficher cette valeur depuis la procédure pour démontrer cela. Utilisez l'extrait de code ci-dessous pour complèter votre procédure btActionClick :

procedure TfmPrinc.btActionClick(Sender: TObject);
begin
  fTest := 10;
  ShowMessage(IntToStr(fTest));
end;

Vous pouvez constater qu'on utilise fTest comme une propriété, mais ce n'en est pas une, et fTest ne peut pas non plus être en lecture seule.

Voilà, vous avez modifié une classe pour la première fois. Maintenant, il faut savoir que le champ que nous avons utilisé était très simple, mais que rien n'empêche d'utiliser des types comme les tableaux, les enregistrements, les pointeurs et les objets.

Nous allons maintenant ajouter une méthode à la classe TfmPrinc. Pour goûter à tout, nous allons la déclarer dans la section publique de la classe et déplacer fTest dans la section privée. La méthode, nommée SetTest, servira en quelque sorte d'intermédiaire entre l'extérieur de la classe (qui aura accès à la méthode mais pas au champ) et l'intérieur pour nous permettre de refuser certaines valeurs. Voici la nouvelle déclaration de la classe :

TfmPrinc = class(TForm)
  btAction: TButton;
  procedure btActionClick(Sender: TObject);
private
  { Private declarations }
  fTest: Integer;
public
  { Public declarations }
  procedure SetTest(Valeur: Integer);
end;

Maintenant que la méthode est déclarée, il va falloir écrire son code. Pour cela, il ne faut pas oublier que SetTest est une méthode interne à TfmPrinc et qu'il faudra, pour écrire son code source, lui donner son nom qualifié. Pour ceux qui ne se rappelent pas de ce que ça signifie, il faudra précéder le nom de la méthode par le nom de la classe et un point. Il va de soi que l'ensemble sera écrit dans la partie implémentation de l'unité. Voici donc le squelette du code de la méthode :

procedure TfmPrinc.SetTest(Valeur: Integer);
begin

end;

Pour les heureux posseseurs de Delphi 5, il n'est pas indispensable d'insèrer vous-même ce code : placez-vous sur la ligne de la déclaration de la méthode et utilisez le raccourci clavier Ctrl + Maj + C. Ceci aura pour effet d'écrire automatiquement le code présenté ci-dessus et de placer le curseur entre le begin et le end.

Nous allons complèter cette méthode. Etant donné qu'elle est interne à la classe TfmPrinc, elle a accès au champ fTest. Nous allons fixer fTest à la valeur transmise, uniquement si cette valeur est supérieure à la valeur actuelle. Voici le code à utiliser :

procedure TfmPrinc.SetTest(Valeur: Integer);
begin
  if Valeur >= fTest then
    fTest := Valeur;
end;

Afin de tester la méthode, nous allons l'appeler plusieurs fois avec diverses valeurs et afficher ensuite la valeur résultante de fTest. Voici un nouveau contenu pour la procédure btActionClick :

procedure TfmPrinc.btActionClick(Sender: TObject);
begin
  SetTest(10);
  SetTest(30);
  SetTest(20);
  ShowMessage(IntToStr(fTest));
end;

Le message résultant affiche bien évidemment 30. Ce n'est encore une fois pas le résultat qui compte. mais la méthode employée.

Comme vous pouvez le constater, modifier une classe existante n'est pas très compliqué. Lorsque l'on ajoute un élément à une classe, il faut cependant essayer de respecter une règle : on place en priorité les éléments dans la section privée, et on ne les place dans la section publique que lorsque c'est nécessaire.

Maintement que vous avez de bonnes bases sur les objets et les classes, il est un sujet qu'il nous est enfin possible d'aborder. Ce sujet requièrerait d'ailleurs de plus grandes connaissances sur les objets, mais nous allons tenter de faire sans.

Comme le titre de ce paragraphe le suggère, il s'agit ici des paramètres - de procédures et de fonctions - dont les types sont des classes (ce qui implique donc que les paramètres eux-mêmes sont des objets). Voici immédiatement un premier exemple qui devrait vous être quelque peu familier :

procedure TForm1.Button1Click(Sender: TObject);
begin

end;

Cet extrait de code, comme vous vous en doutez (j'espère !), est le squelette d'une procédure associée à un événement OnClick. Cette procédure, qui fait, soit dit en passant partie de la définition de la classe "TForm1", a un trait particulier qui nous intéresse davantage ici : elle accepte un unique paramètre de type "TObject". Or "TObject" est un objet, ce qui fait que le paramètre appelé "Sender" est de type objet.

Cet exemple est toutefois peu intéressant car la classe "TObject" n'est pas très développée. Imaginons maintenant que nous ayons besoin de changer le texte d'un bouton sur une fiche, mais sans utiliser le nom de ce bouton. Ceci permettrait par exemple de changer le texte de n'importe quel bouton avec cette procédure. Nommons-là "ChangeTexte". Cette procédure doit agir sur un bouton, c'est-à-dire sur un objet de classe "TButton". Le premier paramètre de la procédure sera donc de cette classe. Nous allons également transmettre à la procédure le texte à écrire sur le bouton, ce qui se fera par un paramètre de type chaîne. Voici le squelette de cette procédure :

procedure ChangeTexte(Bt: TButton; NouvTxt: String);
begin

end;

Depuis cette procédure, "Bt" doit être considéré comme un véritable objet de classe "TButton", comme le paramètre "NouvTxt" qui est considéré comme une vraie chaîne de caractères. On a tout à fait le droit d'accèder à la propriété "Caption" de "Bt" puisque c'est un bouton. Nous allons donc écrire l'unique instruction de la procédure ainsi :

procedure ChangeTexte(Bt: TButton; NouvTxt: String);
begin
  Bt.Caption := NouvTxt;
end;

Il faudra cependant faire très attention avec les paramètres de type objet, car contrairement aux types simples qui ont toujours une valeur, et similairement aux pointeurs qui peuvent valoir nil, les paramètres de type objet peuvent également ne pas être corrects, s'ils sont non construits par exemple. Un bon moyen pour savoir si un objet est valide est d'utiliser la fonction "Assigned". Cette fonction particulière qui accepte un peu n'importe quoi comme paramètre (pointeurs et objets sont acceptés) renvoie un booléen renseignant sur l'état du paramètre : faux indique pour un pointeur qu'il vaut nil, et pour un objet qu'il est invalide, vrai indique que le pointeur n'est pas nil, ou qu'un objet est correctement construit.

Nous éviterons donc des erreurs en modifiant la procédure "ChangeTexte" de cette manière :

procedure ChangeTexte(Bt: TButton; NouvTxt: String);
begin
  if Assigned(Bt) then
    Bt.Caption := NouvTxt;
end;

Avec cet exemple, vous voyez que l'on manipule les paramètres de type objet comme les autres paramètres, hormis le fait qu'on prend un peu plus de précaution en les manipulant, ce qui est tout à fait compréhensible vu la complexité des classes. Nous allons maintenant voir que cette apparente simplicité cache en fait bien plus.

Dans l'exemple de la procédure "Button1Click" ci-dessus, on serait en droit de croire que "Sender" est alors de classe "TObject", ce qui serait tout à fait légitime vu ce qui précède dans tout ce chapitre. En fait, ce n'est pas toujours le cas. En réalité, "Sender" peut effectivement être de classe "TObject", mais également de toute classe descendante de la classe "TObject". Ainsi, "Sender" peut très bien être de classe "TComponent" ou "TButton" par exemple, mais aussi "TObject". Ceci signifie qu'on peut transmettre en tant que paramètre de type classe n'importe quel objet dont la classe est ou descend de la classe du paramètre dans la déclaration de la procédure/fonction.

Pas d'affolement, je m'explique : considérons une procédure "Toto" qui a un paramètre "Obj" de classe "TMachin". On peut alors appeler "Toto" en donnant comme paramètre soit un objet de classe "TMachin", soit un objet dont la classe descend de "TMachin". Par exemple, si la classe "TSuperMachin" descend de "TMachin", alors tout objet de classe "TSuperMachin" peut être transmis en tant que paramètre de "Toto". Voici une déclaration possible pour "Toto" :

procedure Toto(Obj: TMachin);

Mais cette liberté dans le choix des classes des paramètres objets a une limite : à l'intérieur de la procédure, un paramètre de classe "TMachin" n'est plus de classe "TSuperMachin". Ceci signifie que même si vous transmettez un paramètre de classe "TSuperMachin" à la procédure "Toto", cette dernière considérera que votre paramètre est de type "TMachin", et perdra donc tout ce qui a été ajouté à "TMachin" pour en faire "TSuperMachin".

Imaginons par exemple qu'une méthode "SuperMethode" soit ajoutée à "TSuperMachin" (elle ne figure pas dans "TMachin", nous supposerons également pour faire simple que cette méthode n'a pas de paramètres). Supposons aussi que nous avons un objet "SuperObjTest" de classe "TSuperMachin". Depuis l'extérieur de la procédure "Toto", vous pouvez appeler "SuperMethode" (à condition toutefois que cette méthode soit dans la section publique de la classe "TSuperMachin") de la manière habituelle, à savoir :

SuperObjTest.SuperMethode;

Depuis l'intérieur de la procédure "Toto", "Obj" est considéré de classe "TMachin", c'est-à-dire que si vous écrivez ce qui est présenté ci-dessous, vous aurez une erreur :

procedure Toto(Obj: TMachin);
begin
  Obj.SuperMethode; { <-- Ceci est interdit !!! }
end;

Pourquoi une erreur ? Simplement parce que la méthode "SuperMethode" n'est pas définie au niveau de la classe "TMachin", mais seulement par l'une de ses classes descendantes. Un objet de classe "TMachin" (Obj) ne possède pas de méthode "SuperMethode", et donc une erreur est affichée en vous indiquant que la méthode "SuperMachin" est inconnue.

Ceci termine la partie cours de ce premier chapitre consacré aux objets. Le prochain chapitre va vous permettre de respirer un peu car le sujet évoqué, les fichiers, bien qu'important, est à mon sens un sujet plus abordable que les objets.