Skip Navigation Links
Accueil
Java Standard EditionExpand Java Standard Edition
Java EE 5Expand Java EE 5
Visual Basic .Net 2005Expand Visual Basic .Net 2005
Visual C++ .Net 2005Expand Visual C++ .Net 2005
Visual C# .Net 2005Expand Visual C# .Net 2005
Cours ASP .Net 2.0Expand Cours ASP .Net 2.0
PostgresqlExpand Postgresql
LinuxExpand Linux
Visual Studio 2008Expand Visual Studio 2008
ASP 3.0 ClassiqueExpand ASP 3.0 Classique
Cours Javascript - DOM - DHTMLExpand Cours Javascript - DOM - DHTML
Cours AjaxExpand Cours Ajax
VBAExpand VBA
AssembleurExpand Assembleur
PerlExpand Perl
MembresExpand Membres
L'auteur du site
Nouveautés sur le site
Contacts
Plan du site
Accueil > Java Standard Edition > La bibliothèque Swing en Java
____________________________________________________________________________________________________
Connexion

LA BIBLIOTHEQUE SWING EN JAVA

12/12/2007

I) Généralités sur Swing

Pour les composants( « contrôles » en vocabulaire Microsoft) communs avec AWT, comme les Frame, les classes Swing possèdent le même nom que la classe AWT, mais avec un « J » devant. Exemple : JFrame en Swing, et Frame en AWT. Il n’existe aucune grosse différence par rapport avec la programmation AWT.
Les développeurs de Swing ont pensé à une espèce de compatibilité avec Swing. Ainsi on récupère aussi les méthodes de AWT, dans les classes Swing correspondantes, afin de faciliter l’apprentissage de Swing. Mais certaines méthodes rapatriées peuvent devenir « deprecated »( dépréciées). On vous conseille alors la méthode la mieux appropriée.

Par contre la gestion des évènements ne change pas de AWT.

I.1) Les imports

Vous aurez besoin d’un import javax.swing.* pour avoir accès à tous les composants Swing :

javax.swing.* ( « javax.swing » est l’équivalent d’un espace de nom en .net . On peut remarquer que le « j » et le « s » ne commencent pas par une majuscule. Au contraire des classes Java. On pourra alors aisément différencier les espaces de nom des classes).

Et vous aurez besoin de import.awt.event.* pour la gestion des évènements, et de import java.awt.* pour le gestionnaire FlowLayout(gestionnaire de positionnement, que nous verrons) .

import awt.event.*
import java.awt.*

I.2) Soyons plus concret

- Il faut se créer une classe de fenêtre, qui dérive de Jframe( javax.swing.Jframe).
public class maFenetre extends javax.swing.Jframe
{

}

- Déclarez en attribut les éléments de contrôle( synonyme de composant, ou encore de « contrôle » en .net).

public class maFenetre extends javax.swing.Jframe
{
private javax.swing.Jbutton monBouton ;
}
Puis instanciez ces composants :

monBouton = new Jbutton( « Quitter ») ; // « Quitter » est le texte affiché dans le bouton

Et on les ajoute à notre fenêtre :
maFenetre.add( monBouton) ;

I.3) Les gestionnaires de positionnement( ou layout managers)

D’accord, on peut très bien uniquement indiquer la taille et la position de chaque composant. Mais cela possède de multiples désavantages, ne serait-ce que la difficulté à écrire le code. Et aussi une dépendance à la taille de la fenêtre qui est embêtante( pour diverses raisons, en voici une : n’oublions pas qu’on veut pouvoir s’exécuter sous plusieurs systèmes d’exploitation. Ou encore on veut pouvoir changer facilement la taille de la fenêtre).
Le langage Java résoud ce problème avec le concept de gestionnaire de positionnement. Le gestionnaire de positionnement permet d’organiser le placement de ses composants, tout en étant indépendant de l’environnement.
Un gestionnaire de positionnement est forcément rattaché à un conteneur. On le relie grâce à la méthode setLayout( ) du conteneur.

I.3.a) Le FlowLayout

Le FlowLayout est le gestionnaire de positionnement le plus simple. Il est, à mon goût, trop primitif pour répondre à tous les besoins, mais il peut aider si on veut tester rapidement un programme, ou si on a besoin d’un affichage simple. Le mode d’organisation est le suivant : chaque composant ajouté est placé à la suite du dernier composant, et sont centrés. Si la ligne courante n’est pas suffisamment grande pour contenir le dernier composant, une nouvelle ligne est ajoutée.

Remarque : je n’ai pas réussi à changer la taille de la fenêtre avec setSize, lorsqu’un FlowLayout était utilisé pour la fenêtre. Ce qui peut se comprendre, car on va alors contre le principe de positionnement automatique !

Remarque : maFenetre.setVisible(true); permet d’afficher la fenêtre.

Remarque : sans maFenetre.pack(); on ne voit pas les boutons, dans l’exemple, on ne voit que la barre de titre. Permet que la taille de la fenêtre soit adaptée au résultat d’affichage donné par le gestionnaire de positionnement choisi. Mettez le systématiquement ( si vous utilisez un gestionnaire de positionnement), pour être tranquille.

Exemple de fenêtre avec 2 boutons et un label :

import javax.swing.*;

 

import java.awt.*;

 

//!!!!!! CONTIENT LE MAIN !!!!!!!!!!!

 

//17/12/2007

//Auteur: Sabri Koffler, pour site InfKoffler

 

public class MonTypeFenetre extends JFrame{

     

      JButton bouton1;

      JButton bouton2;

      JLabel label3;

     

      public MonTypeFenetre()

      {

                 

            this.setLayout(new FlowLayout());

           

            bouton1 = new JButton("Bouton No1");

            bouton2 = new JButton("Bouton No2");

            label3 = new JLabel( "Label No1");

           

            this.add( bouton1);

            this.add( bouton2);

            this.add( label3);

      }

     

      /**

       * @param args

       */

           

      public static void main(java.lang.String[] args) {

           

            MonTypeFenetre    maFenetre = new MonTypeFenetre();

           

            maFenetre.pack(); //Sans cette ligne, on ne voit pas les boutons,

                                   //on ne voit que la barre de titre.

                                   //Permet que la taille de la fenêtre soit adaptée au

                                   //résultat d'affichage donné par le gestionnaire positionnement choisi.

           

            maFenetre.setVisible(true);  //Permet d'afficher la fenêtre

      }

           

}

I.3.b) Travailler sans gestionnaire de positionnement

   Pour positionner d’une manière très précise et personnalisé, rien ne remplace l’absence de gestionnaire de positionnement, après tout c’est la méthode naturelle de dessin ! Les gestionnaires de positionnement doivent être une aide. S’ils vous embêtent et vous freinent pour votre besoin, n’en utilisez pas !
Il est donc possible de ne pas utiliser de gestionnaire de positionnement. On fixe alors la position du composant, et sa taille, grâce à la méthode setBounds( int, int, int, int) du composant. Les deux premiers paramètres sont les coordonnées du coin supérieur droit, et les deux autres paramètres sont sa largeur et sa hauteur. Dans ce cas, il est indispensable auparavant de faire setLayout(null) ;

Exemple d’application avec une Jframe et un bouton :

import javax.swing.*;

import java.awt.Event.*;

import java.awt.*;

 

public class MonTypeFenetre extends JFrame{

      private JButton monBouton;

     

      public MonTypeFenetre()

      {

            this.setLayout(null); //indispensable si on veut placer librement

            this.setBounds( 200,300, 200, 250);

            monBouton = new JButton("Texte");

            monBouton.setLayout(null);

            monBouton.setBounds(50,100, 100,32);          

            //monBouton.setOpaque(true);

            monBouton.setBackground(new java.awt.Color(0, 0, 0)); //noir

            monBouton.setForeground(new java.awt.Color(204, 204, 204)); //un gris-beige

            this.add( monBouton);       

      }

     

      public static void main(java.lang.String[] args) {

            MonTypeFenetre maFenetre = new MonTypeFenetre();          

            //maFenetre.show(); Marche mais deprecated

            maFenetre.setVisible(true);

      }

}


I.3.c) Les autres gestionnaires de positionnement

Il existe des gestionnaires de positionnement plus élaborés que le FlowLayout. Il existe par exemple le BorderLayout( constructeur BorderLayout( ) ) qui organise le conteneur en cinq zones( Central, North, South, East, West). On ajoute les composants ainsi : add( « South », monComposant).
Il en existe d’autres comme le GridLayout, etc .

II) La gestion des évènements de AWT( s’applique à Swing)

Essayons de comprendre d’abord la gestion des évènements dans AWT, car c’est ce que nous utiliserons pour Swing. Swing permet d’aller plus loin dans la gestion des évènements, mais nous allons commencer par le début.

Les applications à interface graphique restent la majorité du temps à attendre. Elles attendent un évènement de l’utilisateur( frappe au clavier, clic de souris, etc). Le système d’exploitation crée alors un évènement correspondant, et le donne au programme correspondant à la fenêtre où a eu lieu l’évènement. Le rôle de AWT commence ici. AWT utilise le delegation event model : le modèle de délégation des évènements.

II.1)Les écouteurs d’évènements

En AWT, il existe les event sources( sources d’évènements) : ce sont les composants qui peuvent déclencher un évènement. Et il y a les event listener( écouteurs d’évènements). Les écouteurs d’évènements traitent l’évènement.
Un écouteur d’évènement est un objet, qui est d’une classe qui implémente une (ou plusieurs) interface Listener. Pourquoi ce nom « écouteur d’évènements » ? Parce qu’on peut imaginer cet objet comme un écouteur d’évènements, c'est-à-dire un objet qui attend qu’un certain évènement se produise, et qui traite cet évènement lorsqu’il s’est produit. C’est l’équivalent de la classe EventHandler de .net . Pour .net, c’est un traiteur d’évènement : il est vrai qu’on peut voir les choses de cette façon( et c’est peut-être d’ailleurs plus simple à comprendre), et qu’on peut dire que cet objet effectue juste le traitement de l’évènement correspondant. Mais si on veut penser plus purement en terme programmation objet, on se rapproche plus de la façon naturelle de penser, en voyant cet objet comme un écouteur d’évènement( et écouteur ne veut pas forcément dire qu’il ne le traite pas en plus), même si cet objet n’est, en réalité, utilisé que quand l’évènement se produit. C’est pas vraiment lui qui écoute les évènements( c’est le système d’exploitation), mais comme il passe son temps à ne rien faire quand ses évènements n’ont pas eu lieu, on peut dire qu’il attend!. Ce n’est donc pas une vrai écoute, c’est d’avantage une attente qu’une écoute active.

Revenons aux interfaces Listener. Exemple : ActionListener, MouseListener, KeyListener . Ces interfaces sont constituées des déclarations des méthodes qui seront appelées lorqu’un évènement a eu lieu. Plusieurs types d’évènements peuvent se produire( clavier, souris, etc). Chaque type d’évènement possède donc une interface propre, qui est spécifique car une méthode de l’interface correspond à ce qu’il faut exécuter quand un certain évènement du type d’évènement(exemple clavier) s’est produit. Les évènements de chaque type d’évènement n’étant pas forcément les mêmes( il ne se produit pas les mêmes évènements au niveau de la souris ou du clavier, par exemple), chaque type d’évènement a donc besoin d’une interface spécifique.

Votre classe écouteur d’évènements peut bien implémenter plusieurs interfaces Listener. Car vous pouvez bien avoir envie d’utiliser, si vous le souhaitez, un même écouteur d’évènement pour traiter les évènements de la souris et du clavier, par exemple. Et rappelons que les interfaces nous permettent d’en implémenter plusieurs.

Exemple d’interfaces Listener : ActionListener, MouseListener, KeyListener …

Prenons l’exemple de la classe ActionListener : c’est une interface un peu particulière, car elle n’est pas spécifique à une catégorie d’évènement, elle est « générique ». On peut, par exemple, s’en servir pour un bouton. Cette interface possède une seule méthode : la méthode actionPerformed. Dans le cas d’un bouton, le sens rattaché à actionPerformed sera le clic sur ce bouton.

Exemple d’écouteur d’évènements pour pouvoir gérer un clic sur notre bouton: on veut afficher « Appuyé », puis « Enlevé », dans le texte du bouton, à chaque clic sur le bouton.

* Premier fichier : monTypeFenetre.java

import javax.swing.*;

import java.awt.Event.*;

import java.awt.*;

 

//!!!!!! CONTIENT LE MAIN !!!!!!!!!!!

 

//15/12/2007 infkofflerJavaEcoutEv1-0

 

//Exemple d’écouteur d’évènement pour pouvoir gérer un clic

//sur notre bouton: on veut affiché « Appuyé », puis

//« Enlevé », dans le texte du bouton, à chaque clic sur le

//bouton.

 

public class MonTypeFenetre extends JFrame{

     

      JButton boutonAgir; //pas en private, pour être accessible à la classe EcouteurBoutonAgir

     

      public MonTypeFenetre()

      {

            this.setLayout(null); //indispensable si on veut placer librement

            this.setBounds( 200,300, 200, 250);

            boutonAgir = new JButton("Agir");

            boutonAgir.setLayout(null);

            boutonAgir.setBounds(50,100, 100,32);         

            //monBouton.setOpaque(true);

            boutonAgir.setBackground(new java.awt.Color(0, 0, 0)); //noir

            boutonAgir.setForeground(new java.awt.Color(204, 204, 204)); //un gris-beige

            //on se crée un écouteur d'évènement, et on l'ajoute

            boutonAgir.addActionListener(new EcouteurBoutonAgir());

            this.add( boutonAgir);      

      }

     

      /**

       * @param args

       */

           

      public static void main(java.lang.String[] args) {

            MonTypeFenetre    maFenetre = new MonTypeFenetre();

            //maFenetre.show(); Marche mais deprecated

            maFenetre.setVisible(true);

     

      }

}


*Deuxième fichier :

//import java.awt.*;

import java.awt.event.*; // java.awt.event est un package

                        //pour avoir par exemple ActionListener

import javax.swing.*; //pour avoir JButton

 

public class EcouteurBoutonAgir implements ActionListener {

      public void actionPerformed( ActionEvent e) {

            JButton boutonAgir = (JButton) e.getSource();

            if (!boutonAgir.getText().equals("Appuyé"))

            {

                  boutonAgir.setText("Appuyé");

            }

            else //c'est "Appuyé": on l'enlève

            {

                  boutonAgir.setText("Enlevé");

            }

      }

}

 

Telecharger infkofflerJavaEcoutEv1-0-15122007

II.1.a) Remarque sur la différence entre une interface et une classe

On peut en profiter pour donner une autre raison du choix des interfaces : ici on ne veut pas donner du code préécrit, comme permet de le faire un héritage. Ici on est sûr que le code des méthodes ne peut pas être écrit d’avance dans l’interface Listener. Il n’était donc pas possible d’en faire une classe. Sauf à en faire une classe abstraite dont toutes les méthodes seraient abstraites. Mais néanmoins on n’a pas vraiment besoin d’un héritage car ici on ne veut pas enrichir une classe mère. Héritage sous-entend qu’on veut rajouter des attributs et des méthodes à une classe mère, donc on n’est plus dans le concept d’héritage. De plus, on ne peut pas faire d’héritage multiple, donc on serait limité à un type d’évènement par écouteur d’évènements.

II.2)Les Adapter

   Un inconvénient des interfaces Listener est qu’on est obligé d’implémenter toutes les méthodes de l’interface, alors qu’on ne se sert pas toujours de toutes les méthodes. On est par conséquent obligé d’implémenter malgré tout les méthodes inutilisées, en mettant un code vide dedans( qui ne fait rien). Le cas de l’ActionListener est particulier, car cette interface possède une seule méthode, donc le problème ne se pose pas.
   En réponse à ce problème, Java propose les classes Adapter. Une classe Adapter( par exemple la classe WindowAdapter) est une classe qui implémente l’interface correspondante( ici l’interface WindowListener, pour notre exemple). Toutes les méthodes sont donc implémentées, mais ne font rien. Il ne nous reste plus qu’à créer une classe qui hérite de la classe Adapter( ici qui hérite de la classe WindowAdapter), et à réécrire uniquement les méthodes qui nous intéressent.

Par exemple, on veut émettre un bip, lorsque la fenêtre a été « iconifiée ».

Ajoutons une classe à notre application ( nouveau fichier EcouteurFenetre.java):

import java.awt.*; // pour le bip

import java.awt.event.*; // java.awt.event est un package

 

public class EcouteurFenetre extends WindowAdapter

                                   //java.awt.event.WindowAdapter

{

      public void windowIconified( WindowEvent e )

      {

            java.awt.Toolkit.getDefaultToolkit().beep();

      }

           

}


Puis, comme dernière ligne du constructeur MonTypeFenetre, ajoutons

this.addWindowListener(new EcouteurFenetre());


Dans cet exemple, notre classe EcouteurFenetre hérite de la classe WindowAdapter. On redéfinit uniquement la méthode qui nous intéresse : la méthode windowIconified. Remarque : la méthode redéfinie est simplement écrite, sans préciser explicitement que c’est une redéfinition d’une méthode héritée( en .net, on ajoute le mot-clé override).

 

Autre remarque : windowListener est donc un écouteur des évènements concernant la fenêtre elle-même, comme la fermeture de la fenêtre, l’iconification de celle-ci, etc. On comprend donc bien le nom « windowListener ».

 

II.3) Un tableau des Listener et des Adapter

Interface Listener       Classe Adapter                       Méthodes

 

ActionListener           Aucune                                   actionPerformed( ActionEvent)

 

FocusListener             FocusAdapter                        focusGained( FocusEvent)

                                                                                  focusLost( FocusEvent)

 

KeyListener                KeyAdapter                           keyPressed( KeyEvent)

                                                                                  keyReleased( KeyEvent)

                                                                                  keyTyped( KeyEvent)

 

MouseListener            MouseAdapter                       mouseClicked( mouseEvent)

                                                                                  mouseEntered( MouseEvent)

                                                                                  mouseExited( MouseEvent)

                                                                                  mousePressed( MouseEvent)

 

MouseMotion-Listener MouseMotion-Adapter        mouseDragged( MouseEvent)

                                                                                  mouseMoved( MouseEvent)

                                                                                 

ItemListener               Aucune                                   itemStateChanged( ItemEvent)

 

TextListener               Aucune                                   textValueChanged( TextEvent)

 

WindowListener        WindowAdapter                    windowOpend( WindowEvent )

windowClosing( WindowEvent)

windowClosed( WindowEvent )

                                                                                  windowActivated( WindowEvent)

                                                                                  windowDeactivated( WindowEvent)

                                                                                  windowIconified( WindowEvent)

                                                                                  windowDeiconified( WindowEvent)


II.3.b) Les écouteurs en classe interne

   On peut remarquer qu’on aurait pu déclarer nos écouteurs( et nos Adapter) en classe interne de la classe MonTypeFenetre. Cela nous aurait permis de pouvoir accéder, à l’intérieur de la classe écouteur, aux propriétés de la classe MonTypeFenetre, notamment les composants( boutons,etc). Quand on a eu besoin ici d’accéder au bouton, on l’a retrouvé grâce à l’objet e, mais parce que ce bouton était le contrôle sur lequel avait eu lieu l’évènement. Si jamais on avait voulu accéder aux autres composants, on aurait été embêté. Définir la classe comme classe interne( c'est-à-dire comme classe déclarée à l’intérieur de la classe MonTypeFenetre) nous permet de résoudre ce problème. De toutes les façons, ces classes écouteurs sont petites généralement, donc il n’est pas gênant de les définir en classe interne.

II.3.c) L’importance de l’architecture

   Ceci est un exemple de problème rencontré( accessibilité impossible d’attributs), qu’on peut régler en changeant l’architecture de l’application. Il faut bien prendre conscience que l’architecture de l’application est un problème à part entière, qu’on occulte souvent en croyant qu’on va trouver intuitivement la bonne architecture, sans réfléchir. Il est parfois nécessaire de se pencher sur le problème de l’architecture de notre future application, au même titre qu’on se penche sur les problèmes d’algorithmique de l’application.

Notre programme devient alors : ( un seul ficher, MonTypeFenetre.java)

import javax.swing.*;

 

import java.awt.Event.*;

import java.awt.event.ActionEvent;

import java.awt.event.ActionListener;

import java.awt.event.WindowAdapter;

import java.awt.event.WindowEvent;

import java.awt.*;

 

//!!!!!! CONTIENT LE MAIN !!!!!!!!!!!

 

//16/12/2007

//Auteur: Sabri Koffler, pour site InfKoffler

 

public class MonTypeFenetre extends JFrame{

     

      JButton boutonAgir;

     

      public MonTypeFenetre()

      {

            this.setLayout(null); //indispensable si on veut placer librement

            this.setBounds( 200,300, 200, 250);

            boutonAgir = new JButton("Agir");

            boutonAgir.setLayout(null);

            boutonAgir.setBounds(50,100, 100,32);         

            //monBouton.setOpaque(true);

            boutonAgir.setBackground(new java.awt.Color(0, 0, 0)); //noir

            boutonAgir.setForeground(new java.awt.Color(204, 204, 204)); //un gris-beige

            //on se crée un écouteur d'évènement, et on l'ajoute

            boutonAgir.addActionListener(new EcouteurBoutonAgir());

            this.add( boutonAgir);

            this.addWindowListener(new EcouteurFenetre());      

      }

     

      /**

       * @param args

       */

           

      public static void main(java.lang.String[] args) {

           

            MonTypeFenetre    maFenetre = new MonTypeFenetre();

            //maFenetre.show(); Marche mais deprecated

           

            maFenetre.setVisible(true); 

      }

     

      public class EcouteurBoutonAgir implements ActionListener {

            public void actionPerformed( ActionEvent e) {

                 

                  if (!boutonAgir.getText().equals("Appuyé"))

                  {

                        boutonAgir.setText("Appuyé");

                  }

                  else //c'est "Appuyé": on l'enlève

                  {

                        boutonAgir.setText("Enlevé");

                  }

            }

      }

     

      public class EcouteurFenetre extends WindowAdapter

      //java.awt.event.WindowAdapter

      {

            public void windowIconified( WindowEvent e )

            {

                  java.awt.Toolkit.getDefaultToolkit().beep();

            }

 

      }

}


III) Les principaux composants Swing

On peut diviser les classes de Swing en quatre : les classes de composants, les classes de conteneur, les gestionnaires de positionnement et les classes pour la gestion des évènements.

Un composant est un élément graphique servant à construire une interface graphique, par exemple un bouton, une case à cocher etc.... C’est l’équivalent des contrôles en .net .

Un conteneur est un composant spécial qui est capable de contenir d’autres composants. Les conteneurs les plus utilisés sont JFrame et JPanel. On ajoute les composants dans le conteneur, grâce à sa méthode add . Les conteneurs servent à organiser les différents composants dans l’interface graphique. Ils ont un rôle complémentaire aux gestionnaires de positionnement dans l’organisation des composants. Le conteneur sert donc à regrouper différents composants d’une interface graphique, et le gestionnaire de positionnement va définir comment organiser les composants contenus dans ce conteneur. Un gestionnaire de positionnement est rattaché à un conteneur.
La base de l’organisation de l’interface graphique est le panneau( JPanel). Un panneau peut contenir d’autres panneaux.

Un gestionnaire de positionnement permet de définir comment les composants d’un conteneur s’organisent. On définit le gestionnaire de positionnement utilisé grâce à la méthode setLayout du conteneur.

Les principaux composants de Swing :

JFrame Fenêtre

JPanel Conteneur

JButton Bouton

JTextField Champ d’entrée de texte

JLabel Champ de texte statique

JList Liste déroulante

JComboBox Boîte combinée

JScrollBar Barre de défilement

JCheckBox Case à cocher

JRadioButton Bouton radio

JTable

III.1) La classe JComponent

Tous les composants graphiques ( les conteneurs comme les composants) héritent de la classe JComponent. C’est la classe de base de tous les composants Swing. Ils héritent par conséquent de ses méthodes. Il est intéressant de se rappeler cela, car cela signifie que beaucoup de méthodes sont communes à tous les composants, donc si on connaît une méthode d’un composant, on saura utiliser cette méthode pour tous les composants.

Exemple de méthode de la classe JComponent : setBounds, setLayout, addMouseListener, etc.


    java.lang.Object
  java.awt.Component
      java.awt.Container
          javax.swing.JComponent

On remarque dans cet extrait de la javadoc du site de sun, que la classe JComponent hérite de la classe java.awt.Container . Cela nous prouve que les classes awt et swing sont tout-de-même intimement liées, mais nous avions déjà remarqué cela à propos de la gestion des évènements.
Swing s’appuie donc sur les classes AWT, il ne part pas de zéro.
On peut en conclure que l’interface Swing est une couche au-dessus de la couche AWT.

Il peut paraître étonnant que la classe JComponent hérite de la classe Container, mais il existe certainement des raisons à cela.

III.2) La classe JPanel


    java.lang.Object
  java.awt.Component
      java.awt.Container

              javax.swing.JComponent

                  javax.swing.JPanel

III.3) La classe JFrame


    java.lang.Object
  java.awt.Component
      java.awt.Container
          java.awt.Window
              
    java.awt.Frame
               
      javax.swing.JFrame

On remarque que la classe JFrame hérite directement de la classe Frame de AWT.

III.4) Les composants les plus utilisés

JButton :


    java.lang.Object
  java.awt.Component
      java.awt.Container
          javax.swing.JComponent
              javax.swing.AbstractButton
               
      javax.swing.Jbutton

JTextField :


    java.lang.Object
  java.awt.Component
      java.awt.Container
          javax.swing.JComponent
              javax.swing.text.JTextComponent
               
      javax.swing.JTextField

JLabel :


    java.lang.Object
  java.awt.Component
      java.awt.Container
          javax.swing.JComponent
              
    javax.swing.JLabel

JList :


    java.lang.Object
  java.awt.Component
      java.awt.Container
          javax.swing.JComponent
              
    javax.swing.JList

JComboBox :


    java.lang.Object
  java.awt.Component
      java.awt.Container
          javax.swing.JComponent
              
    javax.swing.JComboBox

JScrollBar :


    java.lang.Object
  java.awt.Component
      java.awt.Container
          javax.swing.JComponent
              
    javax.swing.JScrollBar

JCheckBox :


    java.lang.Object
  java.awt.Component
      java.awt.Container
          javax.swing.JComponent
              javax.swing.AbstractButton
               
      javax.swing.JToggleButton
               
          javax.swing.JCheckBox

JRadioButton :


    java.lang.Object
  java.awt.Component
      java.awt.Container
          javax.swing.JComponent
              javax.swing.AbstractButton
               
      javax.swing.JToggleButton
               
          javax.swing.JRadioButton

JTable :


    java.lang.Object
  java.awt.Component
      java.awt.Container
          javax.swing.JComponent
              
    javax.swing.JTable

RETOUR HAUT