article de presse - Cap Data Consulting

P ratique
ment la méthode dispose mérite d'être appelée. Bien évidemment, ça ne
sera pas le cas pour un objet de type Rectangle, alors que ça peut l'être pour
un objet de type GC. Dans ce cas, la règle est simple, si l'objet est fourni par
le runtime Eclipse on ne le libère pas, car le runtime va s'en charger lui
même. Si l'objet est instancié par nous, alors nous devons le libérer. A titre
d'illustration de ce principe, voici l'implémentation du gestionnaire d'événement
Paint de notre vue.
public void paintControl(PaintEvent e) {
Color blue;
Font font;
GC gc = e.gc;
}
gc.setForeground(red);
Rectangle rect =
((Composite)e.widget).getClientArea();
rect.height -= 1;
rect.width -= 1;
gc.drawRectangle(rect);
font = new Font(display,"Times",
24, SWT.ITALIC|SWT.BOLD);
gc.setFont(font);
blue = new Color(display, 0, 0, 255);
gc.setForeground(blue);
FontData[] fd = font.getFontData();
Point pt = gc.textExtent(texte, 0);
gc.drawString(texte, (rect.width - pt.x)/2,
(rect.height - fd[0].height)/2);
blue.dispose();
font.dispose();
Nous voyons que le GC nous est fourni donc pas libéré, tandis que les
polices et couleurs créées par nous sont libérées. Parallèlement, la couleur
rouge obtenue du système (voir extrait de code précédent) n'est pas non
plus libérée. Voici maintenant le code de la méthode qui dessine le second
texte. Nous y voyons comment obtenir un contexte graphique à la volée,
contexte qui doit être libéré.
public void abonnementProgrammez() {
Font font;
String texte = "Abonnez vous! :-)";
Color green = display.getSystemColor(SWT.COLOR_DARK_GREEN);
Rectangle rect = canvas.getClientArea();
GC gc = new GC(canvas);
font = new Font(display,"Times",
24, SWT.ITALIC|SWT.BOLD);
gc.setFont(font);
gc.setForeground(green);
}
5
Programmez n°85 79 avril 2006
FontData[] fd = font.getFontData();
gc.drawString(texte, rect.x + 10,
rect.height - fd[0].height - 20);
font.dispose();
gc.dispose();
Passer à l’action
Jetons maintenant un coup d'oeil au code de la classe ApplicationAction
BarAdvisor. Le Workbench invoque successivement les méthodes
makeActions, fillMenuBar et fillCoolBar. Les noms des deux dernières parlent
d'eux mêmes. On remarque dans le code, que des objets de type Action sont
insérés dans les deux cas, et que le système gère tous les détails de bas
niveau. La première méthode instancie les classes de type Action, dont le
rôle est de diriger des actions possibles de l'utilisateur final (touches clavier,
menu, bouton de barre) vers le code de traitement. L'environnement fournit
des actions standard et il est aussi possible de spécialiser une action par
dérivation de la classe Action. Ce que nous faisons ici :
public class MyAction extends Action {
private final IWorkbenchWindow window;
public MyAction(IWorkbenchWindow window, String label) {
this.window = window;
setText(label);
setId(ICommandIds.CMD_HINT);
setActionDefinitionId(ICommandIds.CMD_HINT);
setImageDescriptor(getImageDescriptor("/icons/progicon.png"));
}
public void run() {
if(window != null) {
MyView myView;
myView =
(MyView)window.getActivePage().findView(MyView.ID);
myView.abonnementProgrammez();
}
}
public static ImageDescriptor getImageDescriptor(String path) {
ImageDescriptor id =
AbstractUIPlugin.imageDescriptorFromPlugin("monrcp", path);
return id;
}
}
Ce code présente de nombreux points intéressants. Nous voyons comment
accéder à une image au moyen org.eclipse.ui.plugin. AbstractUIPlugin, classe
magique dans ce genre de situations. Ensuite la méthode run, qui
contient le traitement de l'action invoque une méthode de notre vue. Nous
avons besoin d'accéder à celle-ci et le code montre un moyen d'y parvenir.
■ Frédéric Mazué fmazue@programmez.com
Niveau
java facile avancé expert