Discussion :

[bleporini]

Bonjour,

Je suis en train de développer une vue qui comprend un bouton déclenchant un traitement. Ce traitement doit libérer l'interface et ne pas la bloquer, or, même en utilisant un déclenchement asynchrone, mon IHM est bloquée par ce traitement.

Voici comment est construit mon bouton:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
okButton = new Button(parent, SWT.PUSH)
[........]
okButtont.addSelectionListener(new SelectionListener(){
 public void widgetSelected(SelectionEvent event){
  parent.getDisplay().asyncExec(new Runnable(){
   public void run(){
     // mon code qui bloque l'ihm
   }
  }
 });

Comme les Action avec les menu fonctionnent bien et ne bloquent pas l'IHM, je me suis dit qu'il serait peut être souhaitable de passer par une Action, par contre je ne sais pas comment "binder" l'action avec les événements du bouton.

Comme j'ai du mal à trouver l'information, il est probable que je fasse fausse route => n'hésitez pas à me réaiguillier

[ewuillai]

Si ton traitement est un peu long, il va effectivement bloquer l'interface pendant son exécution, quel que soit le mode de déclenchement.
En fait le blocage se fait dès lors que le traitement est lancé à partir du thread dédié à l'IHM (le Display).

Pour les traitements longs, la bonne approche consiste à utiliser les jobs.
Pour cela il faut surcharger la classe WorkspaceJob et implémenter la méthode runInWorkspace qui va être exécuter dans un thread à part, géré par le workspace. C'est comme ca notamment que Eclipse gère les compilations en background.

Une fois la classe d'exécution implémentée, le job est lancé de la manière suivante :
- Création d'une instance du job.
- Association d'une règle de scheduling.
- Lancement.

Un exemple issu d'un de mes dév :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
static class CopyrightJob extends WorkspaceJob {
    CopyrightSettings settings;
 
    public CopyrightJob(CopyrightSettings settings) {
      super(Messages.CopyrightManager_jobName);
      this.settings = settings;
    }
 
    @Override
    public IStatus runInWorkspace(IProgressMonitor monitor) {
      try {
        return applyCopyright(settings, monitor);
      } catch (CopyrightException e) {
        return new Status(IStatus.ERROR, Activator.PLUGIN_ID, e.getMessage(), e);
      }
    }
  }
[...]
Job job = new CopyrightJob(settings);
job.setRule(ResourcesPlugin.getWorkspace().getRoot());
job.schedule();

En fait l'appel de la méthode schedule va ajouter le job dans la file des jobs en attente d'exécution. Il sera réellement exécuté lorsqu'il arrivera en tête de la file, suivant la règle de scheduling définie.

La doc Eclipse est assez explicite sur le sujet.

Eric

[bleporini]

J'imagine qu'il s'agit des tâches que l'ont voit s'empiler dans la vue "Progress", non?

Merci pour le snippet je vais tester, je me suis pour le moment débloqué en lançant un thread java dans mon bundle métier, ce que RCP m'autorise puisqu'il n'a aucune dépendance avec l'IHM.

Brice

[ewuillai]

Effectivement, la vue Progress permet de suivre l'avancement des jobs.
L'avantage des jobs par rapport à un simple thread est qu'ils permettent de gérer des règles de scheduling et de concurrence d'accès sur des ressources du workspace.
Si ton traitement ne manipule pas de ressources Eclipse (par ex. IProject ou IFile), alors un simple thread devrait faire l'affaire.

Un autre avantage des jobs est qu'ils sont associés à un objet Monitor qui permet d'en suivre l'avancement, et au besoin de les interrompre (le bouton rouge dans la vue Progress).

Eric

[bleporini]

Arrête moi si je me trompe:
Les jobs semblent ne pas pouvoir s'exécuter de façon concurrente, non? Il semble qu'ils soient gérés sous forme de file d'attente?

Si c'est ainsi, je vais rester sur le thread java car il est dans la couche métier pure et ne manipule aucune entité RCP, d'autant que le cas d'utilisation ne supporterait pas de se retrouver à attendre la fin d'un job pour être exécuté.

++

[ewuillai]

En fait oui et non.
Ils ne peuvent s'exécuter de façon concurrente sur une même ressource.
D'où la définition de règles de scheduling associées à chaque job.

Dans l'exemple que j'ai donné, la ressource indiquée dans la règle est la racine du workspace. Donc effectivement dans ce cas, tous les jobs ayant ce niveau de synchro s'exécutent en séquence.
Il doit être possible de définir des règles plus fines. Je ne l'ai pas fait car j'avais réellement un besoin d'exécuter le job sur l'ensemble des ressources du workspace.
Je t'invite à regarder la doc pour plus de précision sur la définition des règles.

Eric

[bleporini]

Je m'y plonge merci!