| Penser en Java 2nde édition | - | Sommaire | Préface | Avant-propos | Chapitre : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Annexe : A B C D | Tables des matières | - | Thinking in Java |
Ce n'est pas une liste exhaustive, en partie du fait que le modèle d'événements nous permet de créer nos propres types d'événements et listeners associés. De ce fait, on rencontrera souvent des bibliothèques qui ont inventé leurs propres événements, et la connaissance acquise dans ce chapitre nous permettra de comprendre l'utilisation de ces événements.
Dans le tableau ci-dessus, on peut voir que certaines interfaces listener ne possèdent qu'une seule méthode. Celles-ci sont triviales à implémenter puisqu'on ne les implémentera que lorsqu'on désire écrire cette méthode particulière. Par contre, les interfaces listener qui ont plusieurs méthodes peuvent être moins agréables à utiliser. par exemple, quelque chose qu'il faut toujours faire en créant une application est de fournir un WindowListener au JFrame de manière à pouvoir appeler System.exit() pour sortir de l'application lorsqu'on reçoit l'événement windowClosing(). Mais comme WindowListener est une interface, il faut implémenter chacune de ses méthodes même si elles ne font rien. Cela peut être ennuyeux.
Pour résoudre le problème, certaines (mais pas toutes) des interfaces listener qui ont plus d'une méthode possèdent des adaptateurs [adapters], dont vous pouvez voir les noms dans le tableau ci-dessus. Chaque adaptateur fournit des méthodes vides par défaut pour chacune des méthodes de l'interface. Ensuite il suffit d'hériter de cet adaptateur et de redéfinir uniquement les méthodes qu'on doit modifier. Par exemple, le WindowListener qu'on utilisera normalement ressemble à ceci (souvenez-vous qu'il a été encapsulé dans la classe Console de com.bruceeckel.swing) :
Le seul but des adaptateurs est de faciliter la création des classes listener.
Il y a cependant un désavantage lié aux adaptateurs, sous la forme d'un piège. Supposons qu'on écrive un WindowAdapter comme celui ci-dessus :
Ceci ne marche pas, mais il nous rendra fous à comprendre pourquoi, car tout va compiler et s'exécuter correctement, sauf que la fermeture de la fenêtre ne fera pas sortir du programme. Voyez-vous le problème ? Il est situé dans le nom de la méthode : WindowClosing() au lieu de windowClosing(). Une simple erreur de majuscule se traduit par l'ajout d'une méthode nouvelle. Ce n'est cependant pas cette méthode qui est appelée lorsque la fenêtre est fermée, de sorte qu'on n'obtient pas le résultat attendu. En dépit de cet inconvénient, une interface garantit que les méthodes sont correctement implémentées.
Pour nous prouver que ces événements sont bien déclenchés, et en tant qu'expérience intéressante, créons une applet qui surveille les autres comportement d'un JButton, autres que le simple fait qu'il soit appuyé ou pas. Cet exemple montre également comment hériter de notre propre objet bouton, car c'est ce qui est utilisé comme cible de tous les événements intéressants. Pour cela, il suffit d'hériter de JButton name="fnB69" href="#fn69">[69].
La classe MyButton est une classe interne de TrackEvent, de sorte que MyButton peut aller dans la fenêtre parent et manipuler ses champs textes, ce qu'il faut pour pouvoir écrire une information d'état dans les champs du parent. Bien sûr ceci est une solution limitée, puisque MyButton peut être utilisée uniquement avec TrackEvent. Ce genre de code est parfois appelé "fortement couplé" :
Dans le constructeur de MyButton, la couleur des boutons est positionnée par un appel à SetBackground(). Les listeners sont tous installés par de simples appels de méthodes.
La classe TrackEvent contient une HashMap pour contenir les chaînes représentant le type d'événement et les JTextFields dans lesquels l'information sur cet événement est conservée. Bien sûr, ceux-ci auraient pu être créés en statique plutôt qu'en les mettant dans une HashMap, mais je pense que vous serez d'accord que c'est beaucoup plus facile à utiliser et modifier. En particulier, si on a besoin d'ajouter ou supprimer un nouveau type d'événement dans TrackEvent, il suffit d'ajouter ou supprimer une chaîne dans le tableau event, et tout le reste est automatique.
Lorsque report() est appelé on lui donne le nom de l'événement et la chaîne des paramètres de cet événement. Il utilise le HashMap h de la classe externe pour rechercher le JTextField associé à l'événement portant ce nom, et place alors la chaîne des paramètres dans ce champ.
Cet exemple est amusant à utiliser car on peut réellement voir ce qui se passe avec les événements dans son programme.
Maintenant que nous connaissons les layout managers et le modèle d'événements, nous sommes prêts pour voir comment utiliser les composants Swing. Cette section est une visite non exhaustive des composants Swing et des fonctionnalités que vous utiliserez probablement la plupart du temps. Chaque exemple est conçu pour être de taille raisonnable de manière à pouvoir facilement récupérer le code dans d'autres programmes.
Vos pouvez facilement voir à quoi ressemble chacun de ces exemples en fonctionnement, en visualisant les pages HTML dans le code source téléchargeable de ce chapitre.
Swing comprend un certain nombre de boutons de différents types. Tous les boutons, boîtes à cocher [check boxes], boutons radio [radio buttons], et même les éléments de menus [menu items] héritent de AbstractButton(qui, vu qu'ils comprennent les éléments de menus, auraient probablement été mieux nommés AbstractChooser ou quelque chose du genre). Nous verrons l'utilisation des éléments de menus bientôt, mais l'exemple suivant montre les différents types de boutons existants :
On commence par le BasicArrowButtonde javax.swing.plaf.basic, puis on continue avec les divers types de boutons. Si vous exécutez cet exemple, vous verrez que le toggle button (bouton inverseur) garde sa dernière position, enfoncé ou relâché. Mais les boîtes à cocher et les boutons radio se comportent de manière identique, on les clique pour les (dé)sélectionner (ils sont hérités de JToggleButton).
Si on désire des boutons radio qui se comportent selon un "ou exclusif", il faut les ajouter à un groupe de boutons. Mais, comme l'exemple ci-dessous le montre, tout AbstractButton peut être ajouté à un ButtonGroup.
Pour éviter de répéter beaucoup de code, cet exemple utilise la réflexion pour générer les groupes de différents types de boutons. Ceci peut se voir dans makeBPanel(), qui crée un groupe de boutons et un JPanel. Le second argument de makeBPanel() est un tableau de String. Pour chaque String, un bouton de la classe désignée par le premier argument est ajouté au JPanel :
