Lazarus est un environnement de développement intégré associé au langage Pascal Objet. C'est la version open source du logiciel DELPHI de Borland. Ce logiciel facilite en particulier la création d'interface graphique et la programmation évènementielle par un mécanisme de génération automatique de code.
Sous Lazarus une fenêtre s'appelle un formulaire.
Voici par exemple, un formulaire réalisé avec Lazarus:
Ce formulaire comporte trois étiquettes trois zones de texte et un bouton.
Nous avons vu que les zones de texte permettent à l'utilisateur de saisir des données. En fait, elles servent également à afficher des résultats.
Dans notre exemple, les deux zones de texte étiqueté X et Y servent à saisir les deux nombres à additionner. Ce sont les données du programme. La zone de texte étiquetée X+Y sert à afficher la somme de ces deux nombres. C'est le résultat du programme produit par l'ordinateur.
Les étiquettes servent donc en principe à indiquer à l'utilisateur quelle donnée il doit introduire dans la zone de texte située juste à coté ou bien quelle résultat y sera affiché.
Lorsque l'utilisateur clique sur le bouton Additionner après avoir saisi les deux nombres dans les zones de texte prévues à cet effet, le programme affiche le résultat dans la zone de texte étiquetée X+Y.
Un bouton sert donc à déclencher un traitement d'information particulier (dans notre cas l'addition de deux nombres).
La création d'une nouvelle application engendre automatiquement la création d'un formulaire (initialement vide) associé à un fichier source Pascal appelé unité (Unit en anglais).
|
| Le formulaire de départ |
Par défaut, ce formulaire s'appelle Form1 et l'unité Pascal associé, Unit1. Si le développeur ne la renomme pas autrement, elle sera représentée sur disque par le fichier Unit1.pas.
Dès la création du formulaire, l'unité qui lui est associée contient du code Pascal généré automatiquement.
Au fur et à mesure que le programmeur ajoute des composants sur le formulaire, leurs noms apparaissent automatiquement dans le code source. Avec l'exemple précédent du programme d'addition, ce serait Label1, Label2, Label3 pour les étiquettes; Edit1, Edit2, Edit3 pour les zones de texte, Button1 pour le bouton.
Voici le code source de l'unité associé au programme d'addition, après que le programmeur ait déposé les différents composants sur le formulaire.
Ces noms permettrons d'accéder aux composants par programme. Il ne faut pas les confondre avec leurs libellés. Les libellés apparaissent sur l'interface graphique. Les noms quand à eux sont invisibles.
Par exemple, le nom du bouton est Button1, mais son libellé est Additionner.
Pour pouvoir plus facilement identifier les composants dans le programme, le développeur peut leur donner des noms plus significatifs que ceux générés automatiquement par Lazarus. Par exemple BoutonAdditionner au lieu de Button1 pour le bouton, ZoneTexteX et ZoneTexteY pour les zones de texte contenant les deux nombres à additionner, ZoneTexteSomme pour la zone de texte contenant la somme des deux nombres.
La modifications des noms des composants se fait via l'interface graphique de Lazarus. Ils sont alors automatiquement modifiés dans le code.
Voici le code modifié automatiquement après modification des noms.
L'interface graphique de Lazarus est concue pour faciliter la programmation évènementielle.
Rappelons que la programmation évènementielle consiste à associer des gestionnaires d'évènement à des évènements de l'interface graphique. Un évènement est définit par un composant de l'interface et un type d'interruption. Par exemple, un bouton (composant) et un clic sur ce bouton (interruption). Lorsque cet évènement a effectivement lieu les instructions contenues dans le gestionnaire d'évènement sont automatiquement exécutées.
Sous Lazarus, un gestionnaire d'évènement s'appelle une procédure évènementielle.
Pour associer une procédure évènementielle à un composant, le développeur n'a besoin de taper aucune ligne de code. Il lui suffit en gros de cliquer sur le composant et éventuellement de sélectionner le type d'interruption. Un double clic sur un composant sélectionne l'interruption par défaut. La déclaration de la procédure évènementielle est alors automatiquement générée dans le code avec un nom formé à partir du nom du composant et du nom de l'interruption.
Reprenons l'exemple de notre programme d'addition.
Supposons que le dévoppeur souhaite associer une procédure évènementielle au bouton Additionner qui serait activé lorsque l'utilisateur clique sur ce bouton.
Pour cela, il lui suffit de faire un double clic sur ce bouton (schéma) et la déclaration de cette procédure évènementielle sera automatiquement générée dans le code source, avec aucune instruction à l'intérieur.
Le nom de cette procédure est BoutonAdditionnerClick. Il est formé à partir du nom du composant (ici BoutonAdditionner) et du nom de l'interruption (Click = clic de souris).
Le développeur complètera ensuite ce gestionnaire d'évènement en placant des instructions à l'intérieur (entre begin et end), qui seront automatiquement exécutées lorsque l'utilisateur cliquera sur ce bouton.
En général, un programme ne s'exécute pas dans l'ordre des lignes du code source, c'est à dire de la première à la dernière ligne du fichier.
Considérons un programme dont l'interface graphique possède trois boutons A,B et C (figure).
Dans le code source, on a d'abord la procédure évènementiel du bouton B, puis celle du bouton A, puis celle du bouton C. Mais, l'ordre d'exécution de ces procédures est totalement indépendant de l'ordre dans lequel elles figurent dans le fichier source. Cela dépend évidemment de l'ordre dans lequel l'utilisateur cliquera sur les boutons A, B et C. Une même procédure peut même être exécutée plusieurs fois.
Lorsqu'une procédure évènementielle a fini de s'exécuter, le programme retourne dans un état d'attente d'évènement.