Les contrôles usuels

Les contrôles usuels

Il existe de nombreux composants susceptibles d’intervenir dans une interface graphique. Certains sont des conteneurs, c’est-à-dire qu’ils sont destinés à contenir d’autres composants ; c’est notamment le cas des fenêtres (JFrame) et des panneaux (JPanel). En revanche, certains composants ne peuvent pas en contenir d’autres ; c’est le cas des boutons. Ils sont souvent nommés contrôles ou encore composants atomiques.avant de vous lancer dans le développement de vos propres applications. L’expérimentation de bon nombre des exemples de ce chapitre vous permettra de bien connaître les événements qu’ils sont susceptibles de produire, les méthodes permettant de les exploiter, mais aussi leur manipulation par l’utilisateur du programme.L’action de l’utilisateur sur une case à cocher se limite à la modification de son état : passage de l’état coché à l’état non coché, ou l’inverse. Elle s’obtient comme pour un bouton soit par clic, soit par sélection de la case et frappe d’espace. L’état visuel de la case (cochée, non cochée) est géré automatiquement par les méthodes de la classe JCheckBox. On aura souvent besoin d’exploiter une case à cocher de deux façons différentes : • en réagissant immédiatement à une action sur la case,• en cherchant à connaître son état à un instant donné.

Nous savons déjà qu’un écouteur de la catégorie Action doit implémenter l’interface Action- Listener, c’est-à-dire redéfinir la méthode actionPerformed. De même, un écouteur de la catégorie Item doit implémenter l’interface ItemListener ; comme l’interface ActionListener, celle-ci ne comporte qu’une seule méthode, itemStateChanged, d’en-tête : Bien entendu, on n’aura généralement aucun intérêt à traiter le même événement à la fois dans actionPerformed et dans itemStateChanged. Simplement, on pourra profiter de cette redondance pour choisir le type d’écouteur le plus approprié à son problème. On notera cependant que seuls les événements Action disposent de la méthode getActionCommand.En général, pour attribuer un état initial à une case, on utilisera la version appropriée du cons- tructeur de JCheckBox, plutôt que la méthode setSelected. En effet, lors de son appel, Java génère des événements comparables à l’action sur la case (Action et Item).Voici un exemple simple de programme qui introduit dans une fenêtre deux cases à cocher et un bouton portant l’étiquette ETAT. Dans la fenêtre console, nous « traçons » les changements d’état de chacune des deux cases. Par ailleurs, une action sur le bouton ETAT provoque l’affi- chage de l’état des deux cases.Comme la case à cocher, le bouton radio permet d’exprimer un choix de type oui/non. Mais sa vocation est de faire partie d’un groupe de boutons dans lequel une seule option peut être sélectionnée à la fois. Autrement dit, le choix d’une option du groupe entraîne automatique- ment la désactivation de l’option choisie précédemment. En Java, c’est la classe JRadioBut- ton qui vous permet d’instancier un tel objet. Comme celui d’une case à cocher, son constructeur requiert obligatoirement un libellé qui sera toujours affiché à côté de la case pour en préciser le rôle :

Cependant, si l’on se contente d’ajouter (par add) de tels objets à un conteneur, on obtient des composants qui, exception faite de leur aspect, se comporteront exactement comme des cases à cocher. Pour obtenir la désactivation automatique d’autres boutons radio d’un même groupe, il faut de plus :Notez que l’objet de type ButtonGroup sert uniquement à assurer la désactivation automati- que d’un bouton lorsqu’un autre bouton du groupe est activé. Cet objet n’est pas un compo- sant. En particulier, on ne peut pas ajouter un groupe à une fenêtre ou à tout autre conteneur ; il faut toujours ajouter individuellement chacun des boutons du groupe au conteneur.Autrement dit, si l’on sélectionne un nouveau bouton radio d’un groupe, on obtient bien un événement Action pour ce bouton, ainsi qu’un événement Item pour chacun des deux boutons dont l’état a changé. Dans ces conditions, on voit que l’événement Item prend tout son inté- rêt puisqu’il permet de cerner les changements d’états. Mais lorsqu’on agit sur un bouton radio déjà sélectionné, on obtient aussi un événement Action (ce qui n’est pas trop choquant), mais aussi malheureusement un événement de type Item Là encore, pour attribuer un état initial à un bouton radio, il est préférable d’utiliser le cons- tructeur plutôt que setSelected. Dans le second cas, Java générerait un événement comparable au changement d’état du bouton (Action et Item).Voici deux exemples simples de programmes qui créent tous deux un groupe de trois boutons radios, le premier étant initialement sélectionné. Un bouton portant l’étiquette ETAT permet d’afficher l’état de chacun des trois boutons. Le premier programme se contente de « tracer » les événements Action, tandis que le second « trace » en plus les événements Item. Dans les deux cas, l’exemple d’exécution correspond aux mêmes actions, à savoir un clic sur : bouton 2, état, bouton 3, état, bouton 3 (à nouveau), état.