Discussion :

[maelstrom]

Bonjour,

J'aurais besoin de savoir comment Update ou refresh un part. J'en ai besoin car j'ai une part qui doit afficher tel ou tel chose selon ce qu'on sélectionne dans une autre. Du coup ma Part se construit de cette façon :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
	@PostConstruct
	public void createControls(Composite parent)
	{
		if(pickedState.getSelectedObjects() == truc)
		{
 
                 }
                 else
                 {
 
                  }

Et pour l'actualiser actuellement j'ai créer un Handler qui détruit la Part et qui la reconstruit au moment ou je change de chose que je sélectionne, cependant ça ne marche pas très bien, c'est moche, et je suis pratiquement sûr qu'il y a une meilleure façon de faire mais je ne la trouve pas.

Voici mon handler actuel :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
@Execute
	public void execute(EPartService partService, MApplication application, EModelService modelService)
	{
		MPart oldPart = partService.findPart("net.zephyr.graphicInterface.parts.PropertiesPart");
        partService.hidePart(oldPart);
		// create new part
		MPart newpart = oldPart;
		// get the part stack and show created part
		List<MPartStack> stacks = modelService.findElements(application, null, MPartStack.class, null);
		stacks.get(3).getChildren().add(newpart);
		partService.showPart(newpart, PartState.VISIBLE);	
	}

Peut-être que ma façon de penser est erroné dès le départ, si vous avez une meilleure solution faites en moi part

[joel.drigo]

Salut,

Oui, c'est sûr recréer le "part" est une mauvaise solution. Au pire, recréer le contenu du Composite parent passé en paramètre de createControls :

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
 
/* ... */
private Composite content;
 
 
public void createControls(Composite parent)
	{
           content = new Composite(parent, SWT.NONE);
           content.setLayoutData( GridDataFactory... );
           content.setLayout( GridLayoutFactory... );
           fillContent();
 
}
 
/* ... */
 
protected void refresh() {
     removeContent(); // dispose les widgets mis dans content
     fillContent();
}
 
/* ... */

Maintenant, il faudrait savoir exactement :

• le contenu du part (si c'est un StructuredViewer, on peut appeler setInput() pour faire la mise à jour de l'affichage par exemple) ;
• Sur quel évenement la mise à jour doit s'effectuer (en général sur changement de sélection, mais ça peut être autre chose) ;
• quel type de Part ? Vue, Editeur ?

[maelstrom]

En gros c'est une Part qui va afficher des Label, Text et TableViewer différents selon l'objet sélectionné. Je construit mes Part avec windowBuilder et j'utilise des objets SWT. Comme le nombre et l'emplacement diffère selon l'objet sélectionné, j'avais pensé à mettre sa dans un if et de construire la Part selon l'objet sélectionné. Cependant comme je l'ai dit ça ne marche qu'une fois.

L’événement se gère au changement de sélection, quand la sélection change j'appelle le Handler.

Mon composite est comme cela pour l'instant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
@PostConstruct
	public void createControls(Composite parent)
	{
		ScrolledComposite scrolledComposite = new ScrolledComposite(parent, SWT.BORDER | SWT.H_SCROLL | SWT.V_SCROLL);
		scrolledComposite.setLocation(149, 0);
		scrolledComposite.setExpandHorizontal(true);
		scrolledComposite.setExpandVertical(true);
 
		Composite composite = new Composite(scrolledComposite, SWT.NONE);
		composite.setLayout(new GridLayout(8, false));
         }

[joel.drigo]

Déjà, pour la réaction au changement de sélection, tu peux simplement enregistrer un écouteur sur le changement de sélection sur le viewSite de la vue.

Ensuite, tu parles de créer des composants différents en fonction de la sélection, ça me semble pas très compatible avec windowbuilder, qui sert plutôt à faire des interfaces statiques. Ou alors tu as un nombre fini et limité de formulaires très différent (construire des formulaires dynamiquement est plutôt simple).

Mais peu importe, fais une série de classes qui étendent Composite, une par type de formulaire. Pour créer un formulaire il suffit d'instancier l'un de ces Composites et pour le détruire d'appeler dispose() sur cette instance.
Autre solution, si l'impact mémoire n'est pas génant, créer tous les Composites possibles, les mettre dans un StackLayout, et sélectionner le bon au changement de sélection.

Le remplissage des données se faisant à part évidemment.

[maelstrom]

Des formulaires différents je risque d'en avoir 15-20 peut-être plus donc la dernière solution me semble un peu trop rude pour la mémoire.

Après l'exemple de code que je t'ai mis c'était le début de ma Part le tronc commun à tous mes formulaires avant le if :

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
23
24
25
26
27
28
@PostConstruct
public void createControls(Composite parent)
{
	ScrolledComposite scrolledComposite = new ScrolledComposite(parent, SWT.BORDER | SWT.H_SCROLL | SWT.V_SCROLL);
	scrolledComposite.setLocation(149, 0);
	scrolledComposite.setExpandHorizontal(true);
	scrolledComposite.setExpandVertical(true);
 
	Composite composite = new Composite(scrolledComposite, SWT.NONE);
	composite.setLayout(new GridLayout(8, false));
 
        if(pickedState.getSelectedObjects() == truc)
	{
                Label lblIndex = new Label(composite, SWT.NONE);
		lblIndex.setText("Index :");
 
		textIndex = new Text(composite, SWT.BORDER);
		textIndex.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, true, false, 1, 1));
         }
         else
         {
                Label lblLength = new Label(composite, SWT.NONE);
		lblLength.setText("Length (m) :");
 
		textLength = new Text(composite, SWT.BORDER);
		textLength.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, true, false, 1, 1));
         }
}

(C'est un exemple il y a évidemment beaucoup plus de paramètre et d'objet différent).

Le problème n'est pas à gérer le changement de sélection ça je le gère déjà.

J'ai une question par rapport au formulaire dynamique, ça à l'air très bien, mais peut-on gérer 10-15 formulaires radicalement différents avec cela ?
Deuxièmement Avec l'exemple de code que je t'ai montré penses-tu que la solution de créer une classe qui étendent Composite, une par type de formulaire est toujours une bonne solution ? Car je vois bien comment désafficher avec cette solution grâce au dispose(), mais je ne vois pas comment ré afficher le bon formulaire (faut-il créer une fonction pour chaque formulaire qui instancie le bon Composite ?)

[joel.drigo]

Les classes qui étendent Composite (une par type de formulaire donc), peuvent être bien étendre une abstraction qui étend composite et qui représente le formulaire type. Pour la sélection de la bonne classe de composite, tu peux procéder par adaptation, ce qui permet en plus au part d'être indépendant des objets sources de données, et surtout de s'occuper du code du formulaire dans une classe isolée du reste, ce qui simplifie le boulot.

L'abstraction aura juste trois méthodes, au moins (Si tu as besoin de gérer des actions (de vue), il te faudra éventuellement d'autres méthodes pour s'interfacer avec l'implémentation concrète) :

• une pour créer les controls en passant le bon parent
• une pour détruire le composant
• une pour injecter les données (à la manière de setInput de Viewer)

Après, la question est de savoir si les formulaires sont complètement différents ou partiellement différents. Dans le second cas, tu peux simplement avoir des méthodes utilitaires qui construisent des parties du formulaire (par exemple une méthode qui construit une section avec un TableViewer). Ensuite, chaque implémentation de l'abstraction fait appel (ou pas) à ces méthodes, ce qui permet de construire un formulaire spécifique.