Programmation objet

Pour introduire la notion de classe, nous prendrons comme exemple la classe TStringList du Pascal, qui permet de manipuler des listes de chaînes de caractères.

Cette classe possède (entre autres) deux attributs nommés Count et Strings et quatre méthodes nommées Clear, Add, IndexOf et LoadFromFile :

• Count est un attribut de type entier destiné à contenir le nombre d'éléments de la liste ;
• l'attribut Strings quant à lui contient la liste des chaînes de caractères ;
• la méthode Clear est une procédure sans paramètre qui permet de vider une liste ;
• la méthode Add est une procédure à un paramètre (de type String), qui permet d'ajouter une chaîne de caractères à une liste ;
• la méthode IndexOf est une fonction à un paramètre de type String. Elle retourne la position d'une chaîne de caractères dans la liste. La position de la première chaîne est 0, celle de la deuxième 1, etc. Si la chaîne n'est pas dans la liste, IndexOf retourne -1 ;
• la méthode LoadFromFile est une procédure à un paramètre de type String représentant le nom d'un fichier. Elle remplit la liste avec les lignes contenues dans ce fichier. C'est donc un moyen pratique pour initialiser la liste des chaînes de caractères contenues dans un objet de la classe TStringList.

À partir du moment où une classe est définie, il est possible de créer des instances de cette classe ou, autrement dit, des objets.

Par comparaison avec un type structuré, la création d'une instance peut être comparée à la déclaration d'une variable de type structuré.

Il y a pourtant une différence importante avec la déclaration d'une variable de type structuré : la déclaration d'un objet n'alloue pas d'espace mémoire pour cet objet, mais pour un pointeur sur cet objet.

Prenons un exemple. Le code suivant ressemble à la déclaration d'une variable de type TStringList :

var Mayonnaise: TStringList;

En réalité, cette ligne de code déclare l'adresse d'un objet (encore inexistant à ce stade) de la classe TStringList. Pour l'instant, cet objet n'existe pas et par conséquent, son adresse est indéfinie.

Pour créer un objet, une deuxième opération appelé instanciation est nécessaire.

En Pascal, l'instanciation se fait par l'intermédiaire d'une méthode spéciale nommée Create, définie pour toutes les classes.

Voici, par exemple, l'instanciation d'un objet de la classe TStringList :

Mayonnaise := TStringList.Create ();

C'est uniquement lors de l'instanciation :

• que la place mémoire est allouée à un objet. Il s'agit plus précisément de la place mémoire nécessaire à stocker les attributs de cet objet ;
• que l'adresse de l'objet est définie. En effet, la méthode Create retourne l'adresse de la zone mémoire contenant les données de l'objet.

Les objets sont stockés dans une zone spéciale de la mémoire appelée le tas (heap en anglais), utilisée de manière plus générale pour l'allocation dynamique de mémoire.

L'accès aux attributs d'un objet se fait de la même manière que l'accès aux champs d'une structure. On utilise le nom de l'objet, suivi d'un point, suivi du nom de l'attribut.

La définition des attributs d'une classe offre toutefois des possibilités supplémentaires, que nous verrons essentiellement dans la deuxième partie du cours. Mais certaines de ces possibilités apparaissent déjà dans la classe TStringList :

• l'attribut count est en lecture seule, c'est-à-dire que l'affectation d'une valeur à cet attribut provoquera une erreur ;
• l'attribut Strings est l'attribut par défaut de la classe. On peut donc écrire Mayonnaise[1] au lieu de Mayonnaise.Strings[1] pour désigner le deuxième élément de la liste Mayonnaise.

Bien que les méthodes soient des sous-programmes, l'appel d'une méthode ne s'écrit pas comme l'appel d'un sous-programme.

Un des paramètres d'une méthode est forcément un objet de la classe pour laquelle cette méthode a été définie.

Par exemple, toute méthode de la classe TStringList a un paramètre de type TStringList ou, autrement dit, un objet de cette classe.

Mais dans l'écriture de l'appel de la méthode, cet objet ne figurera pas dans les parenthèses, mais en dehors, à gauche du nom de la méthode et séparé par un point. Cette écriture est l'application d'une méthode à un objet.

Voici, par exemple, l'application de la méthode Add (adjonction d'une chaîne) à un objet de la classe TStringList :

Mayonnaise.Add('Oeuf');

Toute méthode s'applique donc nécessairement à un objet de sa classe.

Une autre différence importante avec les sous-programmes se situe au niveau du nom. Le nom d'un sous-programme normal le définit de manière unique. Ce n'est pas vrai pour une méthode.

En effet, deux classes distinctes peuvent avoir des méthodes de même nom qui ne font pas du tout la même chose !

On pourrait, par exemple, imaginer une classe Date avec une méthode Add permettant d'ajouter un certain nombre de jours à une date. L'application de cette méthode à un objet D de la classe Date pourrait par exemple s'écrire :

D.Add(5);

Ce qui aurait comme effet d'ajouter cinq jours à la date D.

Mais dans ce cas, comment le compilateur peut-il distinguer les deux méthodes ?

L'ambiguïté est résolue grâce à la nature de l'objet à laquelle est appliquée la méthode. S'il s'agit d'un objet de la classe TStringList, le compilateur en déduira qu'il s'agit de la méthode Add de la classe TStringList. S'il s'agit d'un objet de la classe Date, il en déduira qu'il s'agit de la méthode Add de la classe Date.

Avec un E.D.I. (comme Lazarus, Visual Basic, Visual C++), la réalisation d'une interface graphique se décompose en deux parties :

• la réalisation du rendu visuel de l'interface. Cette partie ne nécessite aucune programmation. Le développeur sélectionne les composants qu'il veut utiliser dans des palettes de composants et les dépose sur la fenêtre. Il peut ensuite modifier leurs propriétés (position, dimension, couleur, par exemple) ;
• l'écriture des gestionnaires d'évènements ou, autrement dit, la programmation évènementielle. C'est ce qui permettra de rendre l'interface fonctionnelle. C'est ici que des notions de programmation objet vont intervenir.

Lazarus offre un très grand choix de composants graphiques répartis sous 14 onglets :

Par manque de temps, je n'ai pu en présenter qu'une petite partie, principalement ceux de l'onglet Standard et Dialogs (boîtes de dialogue), ainsi que quelques composants des onglets Additional, Common Controls et Misc.

Les onglets Data Controls , Data Access et SQLdb sont spécialisés dans l'accès aux bases de données. Nous en reparlerons dans le cours consacré à l'accès aux bases de données par programmation.

Dans le premier cours (Premières notions), nous avions déjà un peu abordé la création d'interface graphique sous Lazarus.

Dans l'exercice de prise en main de Lazarus, nous avions créé l'interface graphique d'un programme permettant d'additionner deux nombres. Cette interface ne comportait que trois types de composants : les étiquettes, les zones de texte et les boutons.

Pour ajouter un de ces composants à l'interface, il vous suffisait de le sélectionner dans la palette des composants standard :

Rappelez-vous que Lazarus génère un nom par défaut pour chaque nouveau composant déposé sur le formulaire :

et que les noms de ces composants apparaissent dans le code source :

La partie du code représentée ci-dessus est la déclaration d'une classe. Plus précisément, c'est la déclaration de la classe TForm1 qui représente le formulaire de votre application. Le nom TForm qui figure entre parenthèses est le nom d'une autre classe. Il s'agit d'une classe prédéfinie de Lazarus sur laquelle nous reviendrons ultérieurement.

Le texte en blanc est la définition des attributs de la classe TForm1. On voit donc que les attributs de cette classe sont les composants déposés sur le formulaire : les attributs Label1, Label2, Label3 de type TLabel sont les trois étiquettes, les attributs Edit1, Edit2, Edit3 de type TEdit sont les trois zones de texte et enfin l'attribut Button1 de type TButton est le bouton.

En fait, TLabel, TEdit et Tbutton ne sont pas réellement des types, mais des classes prédéfinies de Lazarus. Ainsi, TButton est la classe représentant les boutons, TLabel celle des étiquettes et TEdit, celle des zones de texte.

De manière générale, tous les composants déposés sur l'interface sont des objets appartenant à différentes classes.

Un peu plus bas dans le code, figure la déclaration d'une variable globale nommée Form1 (à moins que cette variable ait été renommée, mais nous supposerons ici pour simplifier les explications que ce n'est pas le cas) :

Avec ce que nous avons vu dans la première partie de ce cours, on comprend qu'il s'agit là de la déclaration d'un objet de la classe TForm1. Le formulaire de l'application est donc également un objet : c'est l'objet Form1 de la classe TForm1. Cette instance de la classe TForm1 est créée automatiquement au démarrage de l'application.

Les composants du formulaire sont donc des attributs de cet objet. Cela explique, par exemple, pourquoi l'écriture Form1.Edit1 peut être utilisée pour désigner la zone de texte Edit1 du formulaire Form1.

Dès qu'un composant a été déposé sur le formulaire, l'inspecteur d'objet permet de modifier ses propriétés. Il suffit pour cela de sélectionner ce composant, puis de sélectionner la propriété voulue dans l'inspecteur d'objet et de modifier la valeur de cette propriété.

La figure suivante illustre, par exemple, la modification de la propriété Caption du bouton du projet Addition :

Les propriétés que l'on modifie ainsi sont en réalité des attributs de l'objet qui représente ce composant. On peut donc également y accéder par programmation. Par exemple, l'instruction :

    Form1.BoutonAdditionner.Caption := 'Additionner';

a le même effet que la modification de propriété illustrée par la figure précédente.

Pour aller un peu plus loin dans la représentation d'une interface graphique sous Lazarus, il nous faut introduire une autre notion fondamentale de la programmation objet : il s'agit de la notion d'héritage.

L'héritage est un mécanisme qui a été introduit dans la programmation objet dans le but d'éviter la réécriture inutile de code lorsqu'une classe n'est qu'un cas spécial d'une autre classe :

La classe plus spécialisée est appelée sous-classe et la classe plus générale, classe mère.

Lorsqu'une relation d'héritage est définie entre deux classes, la sous-classe hérite de tous les attributs et méthodes de la classe mère. C'est-à-dire que tout se passe comme si les attributs et méthodes de la classe mère avaient été explicitement définis pour la sous-classe.

Une sous-classe d'une classe donnée représente donc une sorte de cas particulier de cette classe qui possède des attributs et méthodes supplémentaires et spécifiques.

Revenons un instant sur la déclaration de la classe TForm1 du projet Addition :

et plus précisément sur la première ligne de cette déclaration de classe :

  TForm1 = class (TForm)

Cette ligne de code définit la classe TForm1 comme une sous-classe de TForm.

TForm est une classe prédéfinie de Lazarus qui représente l'interface graphique par défaut, c'est-à-dire un formulaire sans composant. Cette classe possède déjà un certain nombre de méthodes et d'attributs. Par exemple, la méthode Close, qui permet de fermer le formulaire, l'attribut Caption qui permet de lui donner un titre.

Comme TForm1 est une sous-classe de TForm, elle hérite de tous les attributs et de toutes les méthodes de la classe TForm. Vous pouvez donc accéder au titre de votre formulaire par Form1.Caption et le fermer en lui appliquant la méthode Close.

Les attributs spécifiques de TForm1 sont les composants qui ont été déposés sur le formulaire. Ses méthodes spécifiques sont les procédures évènementielles associées à ces composants.

Tout comme TForm1, les composants de l'interface ont des classes mères qui représentent en quelque sorte des « composants abstraits ». La figure suivante montre l'arborescence (très simplifiée) des classes Lazarus intervenant dans la représentation d'une interface graphique :

La classe TControl▲

La classe TComponent▲

La classe TObject▲

Dans les en-têtes des procédures évènementielles, le nom de la procédure est toujours préfixé par TForm1.. Pour quelle raison ?

Le préfixage des procédures évènementielles par TForm1 s'explique par le fait que les procédures évènementielles sont des méthodes de la classe TForm1. Or, lorsque l'on déclare une méthode en Lazarus, il faut obligatoirement préfixer le nom de la procédure par le nom de la classe (nous reviendrons là-dessus plus en détail dans le deuxième cours de programmation objet).

Pour quelle raison les en-têtes des procédures évènementielles apparaissent-elles à l'intérieur de la déclaration de la classe Tform1 ?

L'explication est encore une fois dans la manière de déclarer une méthode d'une classe : en Pascal Objet, les en-têtes des méthodes d'une classe doivent forcément figurer à l'intérieur de la déclaration de la classe.

Dans une procédure non évènementielle, les composants doivent être préfixés par Form1., mais ce n'est pas nécessaire dans une procédure évènementielle. Pour quelle raison ?

Rappelons-nous que les procédures évènementielles sont des méthodes de la classe TForm1 et que les composants sont des attributs de cette classe.

Or, à l'intérieur d'une méthode d'une certaine classe, un nom d'attribut de cette classe désigne implicitement l'attribut de l'objet auquel il sera appliqué au moment de son exécution.

Comme les procédures évènementielles sont des méthodes de la classe TForm1, que les composants sont des attributs de cette classe et que les procédures évènementielles sont forcément appliquées à l'objet Form1 de cette classe, tout nom de composant apparaissant à l'intérieur d'une procédure évènementielle est automatiquement interprété comme un attribut de l'objet Form1. À l'intérieur d'une procédure évènementielle, le préfixage des composants par Form1. est donc inutile.

Par exemple, à l'intérieur de la procédure évènementielle Button1Click du projet Addition, Edit1 désigne implicitement la zone de texte Edit1 de l'objet Form1, car Edit1 est un attribut de la classe TForm1.

D'un autre côté, dans une procédure non évènementielle, le préfixage des composants est obligatoire car, tout simplement, les procédures non évènementielles ne sont pas des méthodes de la classe TForm1 (à moins, bien sûr, de les déclarer en tant que telles).

Dans l'en-tête d'une procédure évènementielle figure toujours un mystérieux paramètre de type TObject nommé Sender. Que représente ce paramètre ?

Le paramètre Sender contient l'adresse du composant qui a déclenché l'évènement. Par exemple, dans la procédure Button1Click :

Sender contient l'adresse de l'objet Button1.

On peut se demander quel est l'intérêt de cela, étant donné que l'on peut tout simplement accéder à cet objet en utilisant son nom.

En fait, l'utilité du paramètre Sender apparaît lorsque l'on cherche à réutiliser la même procédure évènementielle pour plusieurs composants de l'interface.

Il est en effet possible, via l'inspecteur d'objet, d'associer la même procédure évènementielle à plusieurs composants. Ceux-ci peuvent même être de types différents (d'où l'intérêt de déclarer Sender comme un objet de la classe Tobject) !

Pour vous en convaincre, ouvrez ProjetSender dans le dossier exemple. Le formulaire contient un bouton et une case à cocher. Ces deux composants sont associés à la même procédure évènementielle qui affiche le nom du composant sur lequel l'utilisateur a cliqué.

Le code de la procédure évènementielle utilisé par les deux composants est le suivant :

procedure TForm1.Button1Click(Sender: TObject);
begin
  ShowMessage ('Vous avez cliqué sur le composant '
    +(Sender As TComponent).Name);
end;

Ce code utilise le polymorphisme, une notion de programmation objet sur laquelle nous reviendrons dans le cours suivant.

Pour connaître les évènements associés à un composant▲

Pour associer un gestionnaire d'évènement à un composant▲

procedure TForm1.XY(Sender: TObject);
begin
end;

procedure TForm1.BoutonAdditionnerClick(Sender: TObject);
begin

end;

procedure TForm1.ZoneTexteXEditingDone(Sender: TObject);
begin

end;

Dans les applications courantes, il est rare de devoir gérer d'autres évènements que le clic. Les suivants pourront toutefois vous être utiles dans de nombreux cas :

• DblClick : le double-clic. Attention :
• EditingDone : en français, « édition achevée ». Cet évènement est généré dès que l'utilisateur a fini de saisir un texte. Il est par exemple disponible pour les zones de texte. L'évènement se produit dès que l'on appuie sur la touche Entrée ou que l'on quitte la zone de texte en allant, par exemple, cliquer dans une autre zone de texte. On peut donc de cette manière saisir une donnée sans avoir à cliquer sur un bouton pour la confirmer ;
• Create : déclenche la création d'un formulaire et la procédure évènementielle FormCreate, que vous connaissez déjà. Pour être plus précis, cet évènement est déclenché par l'instanciation d'un objet de la classe TForm. Il n'existe donc que pour les composants de cette classe ;
• Resize : évènement déclenché par le redimensionnement d'un composant. Particulièrement utile pour gérer le redimensionnement de la fenêtre d'une application. On peut ainsi, par exemple, redimensionner les composants d'une fenêtre lorsque ses dimensions sont modifiées par l'utilisateur ;
• CloseQuery : généré par la fermeture d'un formulaire. Utile pour protéger l'utilisateur contre une fermeture involontaire de l'application qui pourrait entraîner une perte de données. Cet évènement n'existe que pour les formulaires (classe TForm).

• cet évènement n'est pas disponible pour les boutons ;
• d'après mes expérimentations, on ne peut pas gérer à la fois le clic et le double-clic sur un même composant. Un double-clic implique forcément un clic simple. Le clic simple est géré en priorité. Il y a toutefois une exception pour les zones de liste ;

L'exemple présenté ici se trouve dans le répertoire Exemple-ProgObjet1/Evenement. Il s'agit d'une nouvelle version du programme d'addition fonctionnant sans bouton. Cet exemple illustre l'utilisation des différents types d'évènements dont nous avons parlé précédemment. Voici le formulaire de cette application :

Utilisation de EditingDone▲

procedure TForm1.ZoneTexteXEditingDone(Sender: TObject);
begin
 Additionner ();
end;

procedure TForm1.ZoneTexteYEditingDone(Sender: TObject);
begin
  Additionner ();
end;

Clic sur une étiquette▲

procedure TForm1.Etiquette_XClick(Sender: TObject);
begin
  Effacer(ZoneTexteX);
end;

procedure TForm1.Etiquette_YClick(Sender: TObject);
begin
  Effacer(ZoneTexteY);
end;

Utilisation de Resize▲

procedure TForm1.FormCreate(Sender: TObject);
begin
  DifferenceLargeur := Form1.width - ZoneTexteX.Width;
end;

procedure TForm1.FormResize(Sender: TObject);
var NouvelleLargeur : integer;
begin
  NouvelleLargeur := Form1.width - DifferenceLargeur;
  ZoneTexteX.width := NouvelleLargeur;
  ZoneTexteY.width := NouvelleLargeur;
  ZoneTexteSomme.width :=  NouvelleLargeur;
end;

Utilisation de DblClick, CloseQuery▲

procedure TForm1.FormDblClick(Sender: TObject);
begin
  Form1.Close();
end;

procedure TForm1.FormCloseQuery
   (Sender: TObject; var CanClose: boolean);
begin
  CanClose := Confirmation ('Mise en garde',
  'Voulez-vous réellement quitter l''application ?',
  'Non','Oui');
end;

Nous utilisons depuis longtemps des zones de texte pour lire des données ou afficher des résultats avec les procédures de la librairie entrees_sortie.pas (Lire, LireEntier, LireNombre, Afficher, AfficherEntier, AfficherNombre). Avec ce qui suit, vous allez enfin savoir comment faire cela sans utiliser ces procédures.

Afficher dans une zone de texte▲

   ZT.Text := 'Toto';

Lire une variable depuis une zone de texte▲

   Toto := ZT.Text;

Effacer une zone de texte▲

Exemple▲

procedure TForm1.BoutonAdditionnerClick(Sender: TObject);
begin
  x := StrToInt(zoneTexteX.Text);
  y := StrToInt(ZoneTexteY.Text);
  somme := x + y;
  ZoneTexteSomme.Text := IntToStr(somme);
end;

La classe TStrings ne représente pas un composant graphique particulier, mais elle est utilisée dans les classes TListBox (zones de liste), TMemo (mémo) et TComboBox (combobox) que nous présentons plus loin. C'est la raison pour laquelle il nous faut commencer par présenter cette classe.

Tout comme la classe TstringListExemple de la classe TStringList que nous avons présentée dans la première partie du cours, TStrings est une classe qui permet de manipuler des listes de chaînes de caractères.

En fait, TStringList n'est qu'une sous-classe de TStrings et toutes les méthodes Clear, Add, LoadFromFile, IndexOf ainsi que les attributs Count et Strings, dont nous avions déjà parlé (voir classeExemple de la classe TStringList), ne sont pas des attributs spécifiques de TStringList, mais des attributs hérités de la classe TStrings.

TStrings possède d'autres méthodes dont nous n'avons pas encore parlé, comme SaveToFile et Delete. La première permet de sauvegarder son contenu dans un fichier et la deuxième de supprimer un élément d'indice donné (la première chaîne est indicée 0).

Jusqu'à présent, nous avons utilisé les zones de liste pour afficher du texte sur plusieurs lignes à l'aide des procédure Afficher, AfficherEntier… de la librairie entrees_sorties.pas.

En réalité, les zones de liste servent à autre chose. Elles sont utilisées pour permettre à l'utilisateur de choisir un élément dans une liste de choix.

Dans Lazarus, les zones de liste sont représentées par la classe TListBox. Cette dernière contient, parmi ses attributs, un attribut nommé Items de type TStrings. C'est dans cet attribut que sont stockés les différents choix possibles, sous la forme d'un objet de la classe TStrings.

On pourra donc ajouter un choix dans une zone de liste en appliquant la méthode Add à son attribut Items. De même, on pourra initialiser la liste des choix à partir d'un fichier, en appliquant la méthode LoadFromFile à cet attribut.

L'attribut ItemIndex est l'indice de l'élément sélectionné (le premier est indicé 0). S'il vaut -1, cela signifie qu'aucun élément n'est sélectionné.

L'attribut Sorted est un booléen qui détermine si la liste des choix doit être triée automatiquement par ordre alphabétique.

TlistBox contient (entre autres) une méthode nommée GetSelectedText. Il s'agit d'une fonction qui retourne le choix sélectionné par l'utilisateur. Si aucun choix n'est sélectionné, elle retourne la chaîne vide.

Exemple▲

procedure TForm1.FormCreate(Sender: TObject);
begin
  ZL_Categorie.Items.Add ('Electricite');
  ZL_Categorie.Items.Add ('Jardinage');
  ZL_Categorie.Items.Add ('Materiaux');
  ZL_Categorie.Items.Add ('Plomberie');
end;

procedure TForm1.ZL_CategorieClick(Sender: TObject);
var NomCategorie, NomFichierCategorie : String;
begin
  NomCategorie := ZL_Categorie.GetSelectedText;
  NomFichierCategorie := NomCategorie+'.txt';
  ZL_TypeProduit.Items.LoadFromFile(NomFichierCategorie);
  ZL_TypeProduit.ItemIndex:=0;
end;

Un combobox est une sorte de combinaison entre une zone de texte et une zone de liste. La zone de texte permet à l'utilisateur de saisir un choix qui n'est pas présent dans la zone de liste.

De plus, un combobox prend moins de place qu'une zone de liste, car la liste des choix n'est pas systématiquement déployée.

Voici quelques attributs utiles de la classe TComboBox :

On retrouve les attributs Items et Sorted des zones de listes. Par contre, la méthode GetSelectedText a disparu car le texte sélectionné se retrouve automatiquement dans l'attribut Text.

Autocomplete permet la complétion automatique des choix. Par exemple, s'il existe un choix commençant par un f, dès que l'utilisateur tape f, la zone de texte contiendra automatiquement le premier choix de la liste commençant par f et ce choix sera sélectionné dans la zone de liste. Si ce n'est pas le bon choix, il lui suffira en général de saisir quelques caractères de plus.

Enfin, lorsque l'attribut AutoDropDown vaut True, la liste est déployée dès que l'utilisateur tape un caractère dans la zone de texte.

Exemple▲

procedure TForm1.BT_AfficherChoixClick(Sender: TObject);
begin
  ZT_Vehicule.Text := CB_Vehicule.Text;
end;

Les cases à cocher sont utilisées pour saisir des informations du type vrai/faux ou oui/non. L'état coché/décoché de la case est mémorisé dans l'attribut Checked, de type booléen. Avec Checked = True, la case est cochée. Sinon, elle ne l'est pas.

Exemple▲

procedure TForm1.CC_PetitDejChange(Sender: TObject);
begin
  AfficherLePrix ();
end;

procedure TForm1.CC_DoucheChange(Sender: TObject);
begin
  AfficherLePrix ();
end;

procedure AfficherLePrix ();
var Prix : Double;
begin
  Prix := 40;
  if Form1.CC_PetitDej.Checked then Prix := Prix + 5;
  if Form1.CC_Douche.Checked then   Prix := Prix + 10;
  Form1.ZT_Prix.Text := FloatToStr(Prix);
end;

Les boutons radio s'utilisent pour définir un choix parmi n, lorsque n n'est ni trop petit (pour n=2, on peut tout aussi bien prendre une case à cocher), ni trop grand (il vaut mieux dans ce cas utiliser une zone de liste ou un combobox).

Comme pour les cases à cocher, c'est l'attribut Checked qui définit le fait qu'un bouton radio soit coché ou non.

Par contre, les boutons radio ne se comportent pas exactement comme des cases à cocher. En effet, des boutons radio directement déposés sur le formulaire s'excluent mutuellement : si l'on coche un des boutons radio, les autres sont automatiquement décochés.

Cette interdépendance des boutons radio est gênante lorsque l'on souhaite utiliser des boutons radio pour des choix indépendants. C'est ici qu'intervient le composant GroupBox. Pour rendre deux groupes de boutons radio indépendants, on peut déposer deux GroupBox sur le formulaire, puis mettre les boutons radio du premier groupe dans le premier GroupBox et ceux du second groupe dans le second.

Exemple▲

procedure TForm1.BR_SP95_P1Change(Sender: TObject);
begin
  AfficherPrixPompe1 ();
end;

procedure TForm1.BR_E10_P1Change(Sender: TObject);
begin
  AfficherPrixPompe1 ();
end;

procedure TForm1.BR_Gazole_P1Change(Sender: TObject);
begin
  AfficherPrixPompe1 ();
end;

procedure AfficherPrixPompe1 ();
var Prix :double;
begin

  if Form1.BR_SP95_P1.Checked Then Prix:=PRIX_SP95;
  if Form1.BR_E10_P1.Checked Then Prix:=PRIX_E10;
  if Form1.BR_Gazole_P1.Checked Then Prix:=PRIX_Gazole;

  Form1.ZT_Prix_P1.Text := FloatToStr (Prix);
end;

Les mémos sont en quelque sorte des zones de texte étendues sur plusieurs lignes. Le texte contenu dans un mémo est stocké dans son attribut Lines de type TStrings.

L'attribut WordWrap définit la manière de gérer le passage à la ligne dans le mémo. Sa valeur par défaut est True, ce qui signifie qu'une ligne de texte sera automatiquement coupée et donc répartie sur plusieurs lignes, lorsque la largeur du mémo n'est pas suffisante pour l'afficher en entier. Dans ce cas, chaque chaîne de caractères contenue dans l'attribut Lines ne représente pas nécessairement une ligne de texte unique dans le mémo (tel qu'il est affiché).

Si WordWrap vaut False, une ligne trop longue pour être affichée en entier sera affichée en partie (ce qui dépasse n'est pas visible). Dans ce cas, chaque chaîne de caractères dans Lines correspond à une unique ligne affichée.

L'attribut Scrollbars définit les barres de défilement horizontales ou verticales. Il ne peut y avoir de barre de défilement horizontale que si Wordwrap vaut False, car dans le cas contraire elle n'est d'aucune utilité. Scrollbars a sept valeurs possibles, qui sont des constantes prédéfinies de Lazarus :

• ssVertical : ajout systématique d'une barre de défilement verticale ;
• SsHorizontal : ajout systématique d'une barre de défilement horizontale ;
• SsBoth : ajout systématique des deux barres de défilement ;
• SsNone : aucune barre de défilement ;
• SsAutoVertical : ajout d'une barre de défilement verticale lorsque c'est nécessaire ;
• SsAutoHorizontal : ajout d'une barre de défilement horizontale lorsque c'est nécessaire ;
• ssAutoBoth : ajout d'une barre de défilement horizontale ou verticale, lorsque c'est nécessaire.

Exemple▲

procedure TForm1.BT_OuvrirClick(Sender: TObject);
var NomFichier : String;
begin
  NomFichier := ZT_NomFichier.Text;
  MM_Editeur.Lines.LoadFromFile(NomFichier);
end;

procedure TForm1.BT_EnregistrerClick(Sender: TObject);
var NomFichier : String;
begin
  NomFichier := ZT_NomFichier.Text;
  MM_Editeur.Lines.SaveToFile(NomFichier);
end;

Les menus, comme les boutons, servent à activer différents traitements d'un logiciel. Lorsque le nombre de traitements est important, l'utilisation d'un bouton pour chaque traitement prend trop de place. Dans ce cas, il est préférable d'utiliser des menus. Ce sont en quelque sorte des boutons organisés en listes déroulantes, qui ne se déploient que lorsque l'on clique dessus.

Exemple▲

Présentation de l'interface graphique▲

Utilisation de l'éditeur de menu▲

Gestionnaires d'évènements des menus▲

procedure TForm1.MN_OuvrirClick(Sender: TObject);
var NomFichier : String;
begin
  NomFichier := ZT_NomFichier.Text;
  MM_Editeur.Lines.LoadFromFile(NomFichier);
end;

procedure TForm1.MN_EnregistrerClick(Sender: TObject);
var NomFichier : String;
begin
  NomFichier := ZT_NomFichier.Text;
  MM_Editeur.Lines.SaveToFile(NomFichier);
end;

procedure TForm1.MN_QuitterClick(Sender: TObject);
begin
  Form1.Close();
end;

procedure TForm1.MN_WordWrapClick(Sender: TObject);
begin
  MM_Editeur.WordWrap:= Not MM_Editeur.WordWrap;
end;

procedure TForm1.MN_FullWindowClick(Sender: TObject);
begin
  if MN_FullWindow.Checked then
  begin
    MM_Editeur.Width := Form1.Width - 50;
    MM_Editeur.Height := Form1.Height - 50;
    Label1.Hide();
    ZT_NomFichier.Hide();
  end
  else
  begin
    MM_Editeur.Width := LargeurMemo;
    MM_Editeur.Height := HauteurMemo;
    Label1.Show();
    ZT_NomFichier.Show();
  end;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  LargeurMemo := MM_Editeur.Width;
  HauteurMemo := MM_Editeur.Height;
end;

Les boîtes de dialogues d'ouverture de fichier évitent à l'utilisateur de taper le nom (et éventuellement le chemin) d'un fichier. Elles se présentent de la manière suivante :

Vous en avez certainement utilisé des centaines de fois, car on les trouve dans tous les logiciels utilisant des fichiers. Pour sélectionner un fichier, vous vous déplacez dans l'arborescence des fichiers de l'ordinateur. Une fois le répertoire atteint, il vous suffit de cliquer sur le nom du fichier.

Si l'utilisateur confirme le choix de fichier, l'attribut FileName de la boîte de dialogue contiendra le nom complet du fichier (avec extension et chemin si nécessaire).

Les boîtes de dialogue d'ouverture de fichier permettent également de filtrer les fichiers par leur extension. Par exemple, dans la boîte de dialogue de la figure précédente, seuls les fichiers d'extension « .txt » sont visibles. L'utilisateur ne pourra donc sélectionner qu'un fichier texte. Ceci permet d'éviter l'ouverture de fichiers de format incompatible avec le programme qui les traite.

La boîte de dialogue contient une zone de liste permettant à l'utilisateur de sélectionner un certain type de filtrage. La boîte dialogue suivante, par exemple, présente deux choix de filtrage :

On peut également définir un filtrage autorisant plusieurs extensions. Voici, par exemple, le résultat du filtrage simultané des extensions « *.txt » et « *.pas » :

Le filtrage des fichiers est défini par le contenu de la propriété Filter de la boîte de dialogue. Pour définir son contenu, le plus simple est d'utiliser l'éditeur de filtre. On y accède en cliquant sur les « … » de la propriété Filter dans l'inspecteur d'objet.

Chaque ligne de l'éditeur de filtre représente un choix de filtrage dans la zone de liste. Voici, par exemple, comment définir séparément deux modes de filtrage :

La colonne de gauche est un commentaire pour l'utilisateur. Il sert en principe à expliquer la signification de l'extension. La colonne de droite définit le filtre sous la forme « *.??? », où les trois caractères « ??? » sont ceux de l'extension.

Pour autoriser tous les formats, on utilise la notation « *.* » :

Pour définir un filtrage autorisant simultanément plusieurs extensions, il faut séparer les filtres par des points-virgules :

Les boîtes de dialogue d'enregistrement de fichier fonctionnent selon le même principe que les boîtes de dialogue d'ouverture de fichier, mis à part que le bouton Ouvrir est remplacé par un bouton Enregistrer :

La classe TOpenPictureDialog est une variante de TOpenFileDialog qui permet de visualiser des fichiers images. L'intérêt principal de cette boîte de dialogue est que les fichiers images sont visualisés sous forme d'icônes. Comme ceci, par exemple :

Comme pour la classe TOpenPictureDialog, le fichier sélectionné se retrouve dans l'attribut FileName.

Une couleur est représentée, sous Lazarus, par le type TColor. La boîte de dialogue de sélection de couleur permet à l'utilisateur de sélectionner visuellement une couleur, sans se préoccuper de la manière dont elle est codée en mémoire :

Le programmeur, quant à lui, récupère la couleur dans l'attribut Color. Il pourra ensuite utiliser cette valeur pour affecter cette couleur à n'importe quel composant graphique, sans se préoccuper lui non plus du codage des couleurs.

La police de caractères, c'est-à-dire la manière dont s'affiche une chaîne de caractères à l'écran, est représentée sous Lazarus par la classe TFont, qui possède de très nombreux attributs. La boîte de dialogue de sélection de police permet à l'utilisateur de sélectionner visuellement les propriétés d'une police de caractères :

Le programmeur récupère la police de caractères sélectionnée dans l'attribut Font, sous la forme d'un objet de la classe TFont.

Cette section ne présente pas une boîte de dialogue Lazarus, mais une fonction que j'ai écrite moi-même permettant d'afficher une boîte de dialogue de ce type :

Cette fonction, nommée Confirmation, est intégrée à la librairie entrees_sorties.pas. Si vous regardez son code, vous constaterez qu'elle utilise la fonction QuestionDlg. Il s'agit d'une fonction standard de Lararus, plus complexe et plus générale, permettant d'afficher une boîte de dialogue posant une question à l'utilisateur avec éventuellement plus de deux boutons.

La fonction Confirmation affiche une boîte de dialogue permettant de confirmer l'exécution d'une action potentiellement dangereuse. Elle retourne un booléen : True si l'utilisateur confirme son choix, False sinon.

Dans l'exemple présenté dans la figure ci-dessus, l'appel de la fonction serait :

 Confirmation ('Mise en garde',
  'Voulez-vous réellement quitter l''application ?',
  'Non','Oui');

De manière générale, vous pouvez utiliser cette fonction pour confirmer des choix potentiellement dangereux de l'utilisateur. Voici son en-tête :

 function Confirmation (t,m,td,ta:string) : boolean;

Elle possède donc quatre paramètres de type String :

• t : titre de la boîte de dialogue ;
• m : message affiché dans la boîte de dialogue ;
• td : titre du bouton par défaut ;
• td : titre de l'autre bouton.

Le résultat retourné est True si l'utilisateur ne clique pas sur le bouton par défaut, c'est-à-dire s'il confirme vouloir exécuter l'action potentiellement dangereuse.

L'exemple suivant se trouve dans le dossier Exemple-ProgObjet1/boîteDeDialogue. Il s'agit d'une version améliorée de l'éditeur de texte que nous avons utilisé pour expliquer le principe des menusLes menus (classes TMainMenu et TMenuItem). Cette nouvelle version intègre (entre autres) des boîtes de dialogue pour l'ouverture et l'enregistrement des fichiers.

Le menu Fichier est le même que dans la version précédente :

Le menu Affichage, par contre, a été remplacé par le menu Texte, qui permet de modifier la police de caractères ou la couleur du mémo.

Cette nouvelle version utilise quatre boîtes de dialogue :

• OpenDialog1 est la boîte de dialogue pour l'ouverture des fichiers ;
• SaveDialog1 est la boîte de dialogue pour l'enregistrement des fichiers ;
• FontDialog1 est la boîte de dialogue pour le choix de police ;
• ColorDialog1 est la boîte de dialogue pour choisir la couleur.

Notez que ces boîtes de dialogue ne seront pas immédiatement visibles au démarrage du programme. Pour les afficher, il est nécessaire de leur appliquer la méthode Execute.

Ouverture de fichier▲

procedure TForm1.MN_OuvrirClick(Sender: TObject);
begin
  if (OpenDialog1.Execute()) then
    MM_Editeur.Lines.LoadFromFile(OpenDialog1.FileName);
end;

Enregistrement de fichier▲

procedure TForm1.MN_EnregistrerClick(Sender: TObject);
begin
 if (SaveDialog1.Execute()) then
  if not FileExists (SaveDialog1.FileName)  then
   MM_Editeur.Lines.SaveToFile(SaveDialog1.FileName)
  else
    if
     Confirmation('Mise en garde',
    'Fichier existant.'+
    ' Voulez vous écraser l''ancienne version ?',
     'Ne rien faire','Ecraser')
    then
       MM_Editeur.Lines.SaveToFile(SaveDialog1.FileName);
end;

Choix de police▲

procedure TForm1.MN_PoliceClick(Sender: TObject);
begin
  if (FontDialog1.Execute) then
    MM_Editeur.Font:= FontDialog1.Font;
end;

Choix de couleur▲

procedure TForm1.MN_CouleurClick(Sender: TObject);
begin
  if (ColorDialog1.Execute()) then
    MM_Editeur.Color:=ColorDialog1.Color;
end;

Le composant image permet d'afficher une image provenant d'un fichier. La plupart des formats images courants (jpg, gif, bmp, etc.) sont acceptés. Vous le trouverez sous l'onglet Additionnal :

L'attribut Picture▲

  Image1.Picture.LoadFromFile('Toto.jpg')

  Image1.Picture.Clear();

Attributs définissant la manière d'afficher l'image▲

Exemple▲

procedure TForm1.MN_OuvrirClick(Sender: TObject);
var nfi : string;
begin
  if OpenPictureDialog1.execute() then
  begin
    nfi := OpenPictureDialog1.FileName;
    Image1.Picture.LoadFromFile(nfi);
  end;
end;

Le composant liste de fichiers vous permettra d'afficher les fichiers contenus dans un répertoire et éventuellement d'effectuer un traitement sur ces fichiers. Vous le trouverez sous l'onglet Misc :

La classe TFileListBox représentant ce composant est une sous-classe de TListBox (zone de listeLes zones de liste (classe TListBox)), si bien que tous les attributs et méthodes des zones de liste peuvent être utilisés avec les listes de fichiers.

Le chemin du répertoire associé au composant est mémorisé dans l'attribut Directory.

La liste des fichiers est initialisée au démarrage de l'application. Si l'utilisateur modifie le contenu du répertoire pendant son exécution, la liste des fichiers affichés dans le composant ne sera pas automatiquement réactualisée. Pour la réactualiser, il faut lui appliquer la méthode UpdateFileList.

Exemple▲

procedure TForm1.FileListBox1Click(Sender: TObject);
var nom_fichier : string;
begin
  nom_fichier:=FileListBox1.Directory+'\'+
  FileListBox1.GetSelectedText;
  Image1.Picture.LoadFromFile(nom_fichier);
end;

procedure TForm1.BT_Rafraichir_ListeClick(Sender: TObject);
begin
  FileListBox1.UpdateFileList;
end;

Voyons tout d'abord comment créer une application multifenêtres sous Lazarus. Lorsque vous démarrez la réalisation d'une nouvelle application, vous avez une seule fenêtre :

Par défaut, la classe représentant cette fenêtre est TForm1Déclaration de la classe TForm1 et de l'objet Form1, sous-classe de TFormLa classe TForm, et l'objet représentant votre fenêtre est Form1, déclaré comme objet de la classe TForm1.

L'unité associée à cette classe se nomme par défaut Unit1 et son code sera contenu dans le fichier Unit1.pas.

Pour ajouter une nouvelle fenêtre, sélectionnez l'entrée Nouvelle Fiche du menu Fichier. Cela fera apparaître une nouvelle fenêtre nommée Form2 :

La classe de cette fenêtre se nomme à présent TForm2 et l'unité associée Unit2 sera par défaut enregistrée dans le fichier Unit2.pas.

Dans une application multifenêtres, la fenêtre principale est celle qui va s'afficher en premier au démarrage de l'application (par défaut, les fenêtres secondaires ne s'affichent pas). C'est donc par l'intermédiaire de cette fenêtre que les fenêtres secondaires pourront être affichées. Lorsque l'utilisateur ferme la fenêtre principale, les autres sont automatiquement fermées. Par contre, l'inverse n'est pas vrai : si l'utilisateur ferme une fenêtre secondaire, la fenêtre principale reste ouverte.

Le fenêtre principale joue donc un rôle particulier par rapport aux autres fenêtres.

Mais comment Lazarus sait-il quelle fenêtre sera la fenêtre principale ?

Par défaut, c'est la première fenêtre créée.

Si, par mégarde, vous avez commencé par une fenêtre secondaire, vous pouvez redéfinir la fenêtre principale en éditant le fichier .lpr.

Voici, par exemple, le contenu du fichier lpr pour un projet à deux fenêtres :

program project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Interfaces, // this includes the LCL widgetset
  Forms, Unit1, Unit2
  { you can add units after this };

{$R *.res}

begin
  RequireDerivedFormResource := True;
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.CreateForm(TForm2, Form2);
  Application.Run;
end.

Si vous voulez que Form2 soit la fenêtre principale au lieu de Form1, il suffit d'inverser les appels de la méthode CreateForm :

program project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Interfaces, // this includes the LCL widgetset
  Forms, Unit1, Unit2
  { you can add units after this };

{$R *.res}

begin
  RequireDerivedFormResource := True;
  Application.Initialize;
  Application.CreateForm(TForm2, Form2);
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

De manière générale, la fenêtre principale est celle qui correspond au premier appel de la méthode CreateForm.

Dans une application multifenêtres, je vous conseille de renommer les unités et les fenêtres. Car des noms comme Form1, Form2, Unit1, Unit2… sont très peu évocateurs.

Nommage des unités▲

Nommage des fenêtres▲

type
  TFrm_Principal = class(TForm)
    .
    .
  end;

var
  Frm_Principal : TFrm_Principal;

Notre exemple de projet multifenêtres contient trois unités nommées UnitePrincipale (associée à la fenêtre principale), UniteImage1 (associée à la fenêtre 1) et UniteImage2 (associée à la fenêtre 2).

En ouvrant le projet, vous constaterez que UniteImage1 et UniteImage2 sont importées dans UnitePrincipale :

unit UnitePrincipale;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, FileUtil, Forms, 
  Controls, Graphics, Dialogs, Menus,
  FileCtrl, StdCtrls, UniteImage1, UniteImage2;

Cette importation est nécessaire car l'unité principale contient des instructions agissant sur les composants des deux autres fenêtres.

Pour bien comprendre le code de notre exemple, il est préférable d'avoir lu les parties du cours concernant les menusLes menus (classes TMainMenu et TMenuItem), les listes de fichiersListe de fichiers (classe TFileListBox), les boutons radioLes boutons radio (classe TRadioButton) et les composants imageComposant image (classe TImage).

Précisons que toutes procédures évènementielles décrites ici se trouvent dans l'unité UnitePrincipale associée à la fenêtre principale.

Voici la procédure évènementielle gérant le clic sur une entrée de la liste des fichiers :

procedure TFrm_Principal.FileListBox1Click(Sender: TObject);
var nom_fichier : string;
begin

  nom_fichier:=
   FileListBox1.Directory+ '\' 
   +FileListBox1.GetSelectedText;

  if BR_Fenetre1.Checked then
    Frm1.Image1.Picture.LoadFromFile(nom_fichier)
  else
    Frm2.Image1.Picture.LoadFromFile(nom_fichier);
end;

FileListBox1 est le nom de la liste de fichiers.

La première instruction construit le nom complet du fichier image à partir du chemin du répertoire qui la contient (stocké dans l'attribut Directory du composant FileListBox) et du nom de fichier sélectionné par l'utilisateur.

Le bouton radio étiqueté Fenêtre 1 se nomme BR_Fenetre1. S'il est coché, l'image est affichée dans la fenêtre 1. Sinon, elle est affichée dans la fenêtre 2.

Comme les composants image ne se trouvent pas dans la fenêtre principale, il est nécessaire de préfixer leurs noms par le nom de la fenêtre qui les contient. On accède donc ici au composant image de la fenêtre 1 par Frm1.Image1 et au composant image de la fenêtre 2 par Frm2.Image2.

L'entrée Fenetre1 du menu Voir déclenche l'exécution de la procédure suivante :

procedure 
 TFrm_Principal.MN_Voir_Fenetre2Click(Sender: TObject);
begin
  Frm2.Show;
end;

On applique la méthode Show à Frm2 pour faire apparaître la fenêtre.

L'entrée Fenetre2 du menu Voir utilise le même principe pour la deuxième fenêtre :

procedure 
 TFrm_Principal.MN_Voir_Fenetre1Click(Sender: TObject);
begin
  Frm1.Show;
end;