Discussion :

[jlg_47]

Bonjour,

Pose de mon problème:

J'ai une application avec une Form que j'appelle "mère"; cette Form contient une listView avec différents Items.

Quand l'utilisateur fait un doubleClick sur un Item de la listView l'application ouvre une fenêtre que j'appelle "fille".

Cette fenêtre "fille" permet à l'utilisateur d'agir sur les paramètres de l'Item sélectionné.

L'utilisateur doit pouvoir avoir plusieurs fenêtres "filles" ouvertes en même temps ...

Jusque là pas de problème

Par contre c'est là que mon problème arrive:

Quand l'utilisateur fait un doubleClick sur un Item qui possède déjà une fenêtre fille ouverte, je voudrais que cette fenêtre soit réveillée pour attirer l'attention de l'utilisateur.

Le problème est que chaque fenêtre "fille" une fois ouverte vit sa vie seule et que l'application qui a lancé les fenêtres "fille" connaît tout juste leur existence, mais ne sait rien d'autre ..

Je n'ai aucune idée de comment faire ça proprement.

Si quelqu'un pouvait m'aiguiller ce serait sympa.

Bonne journée

[Médinoc]

Ta fenêtre "fille" (en fait, plutôt une fenêtre "owned") c'est une Form^ (ou classe descendante de Form) également, non?

Tu peux mémoriser sa référence dans ta Form principale une fois qu'elle est ouverte, et interagir avec lors d'un clic...

[bacelar]

WinForms, je suppose.
La méthode Activate de la classe Form.
http://msdn.microsoft.com/en-us/libr...v=vs.110).aspx

Vous faites en sorte que dans le constructeur de la classe du "sous" formulaire, il appel une méthode d'enregistrement de l'objet "formulaire racine".
Dans les méthodes Close du "sous" formulaire, vous appelez une méthode de désenregistrement.
La classe racine n'a qu'a stocker ces références dans une table d'association et appeler la méthode Activate sur ces références au moment opportun.

[jlg_47]

Merci Bacelar,

Je regarde ça dès que je peux.

Avant d'ouvrir la Form "fille" l'application "mère" stocke des données dans un singleton qui sert de boite aux lettres. La Form "fille" s'ouvre et récupère les données, puis vit sa vie indépendamment.

Toutes les Forms "fille" sont ouvertes à partir du même évènement ItemActivate de la listView et de la même façon.

Dans le traitement de l'évènement je recherche d'abord quel Item a été cliqué dans la listView, je stocke les données correspondante à l'Item dans le singleton, puis je lance la fenêtre fille par ces 2 lignes.

Code :

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

1
2
 Formulaire ^ Form2 = gcnew Formulaire;
 Form2->Show (this);

La fenêtre fille en s'ouvrant récupère ses données dans le singleton, puis fonctionne comme une fenêtre indépendante.

L'utilisateur peut alors double cliquer sur un autre Item de la listView et disposer d'une seconde fenêtre, puis d'une 3ième et ainsi de suite.

Bonne soirée

[bacelar]

Pourquoi passer par un singleton.
Le plus simple est de passer par des paramètres du constructeur.
Passez en paramètre aussi le formulaire parent.
Dans le constructeur de votre Form Fille, enregistrez la en appelant un méthode dédiée de votre Form principale.
Dans le Close de la fenêtre de vos fenêtres secondaire, vous appelez la méthode de désenregistrement de votre Form principale.
...
Dans la méthode d'enregistrement de votre Form principale, vous associez la Form secondaire à une clé dans une table d'association.
Dans la méthode de désenregistrement de votre Form principale, vous supprimez cette association.

Dans ItemActivate, on commence par lire la table d'association et faire un Activate sur le formulaire secondaire s'il est enregistré, sinon on crée le formulaire secondaire, en passant en paramètre les informations nécessaires.

[jlg_47]

Pourquoi passer par un singleton.

C'est parce que je ne sais pas faire autrement.

Le plus simple est de passer par des paramètres du constructeur.
Passez en paramètre aussi le formulaire parent.

Je ne me suis jamais trop penché sur la façon utilisée par Visual pour construire les Form ...
Je me contente d'utiliser l'interface graphique.

J'ai beaucoup programmé en assembleur, puis en Fortran et en C et la programmation objet reste encore une science un peu obscure pour moi.

Merci, je vais essayer de comprendre mais pour l'instant il m'a fallu déplacer mes priorités.

Bonne journée.

[bacelar]

Le passage de paramètres, c'est comme en C.

[jlg_47]

Dans ItemActivate, on commence par lire la table d'association et faire un Activate sur le formulaire secondaire s'il est enregistré, sinon on crée le formulaire secondaire, en passant en paramètre les informations nécessaires.

En fait c'est ça que je ne vois pas comment faire ...

Vu de Form1 toutes les Form2 sont les mêmes et comment en réveiller une plutôt qu'une autre ...

Bonne soirée

[Médinoc]

Code :

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

1
2
private:
	Dictionary<int, Form2^> formulairesOuverts;

[Mat.M]

L'utilisateur doit pouvoir avoir plusieurs fenêtres "filles" ouvertes en même temps ...

une interface MDI serait plus appropriée ; est-ce le cas ?

[Médinoc]

Un simple Activate() sur le form devrait suffire. Il m'a fallu moins d'une minute pour trouver ça, en comptant la recherche Google!

[jlg_47]

Un simple Activate() sur le form devrait suffire. Il m'a fallu moins d'une minute pour trouver ça, en comptant la recherche Google!

Désolé, Le problème n'a jamais été au niveau de l' "Activate" .

Je n'aurais pas dû rouvrir un post qui était marqué "résolu" .. Je comprends très bien que vous n'avez pas le temps de relire un post depuis le début.

Le problème était de ne pas générer x fois la même fenêtre dans l'Activate, mais de lui redonner le Focus si elle existe déjà.

Grâce à Bacelar et vous même ce problème est résolu et je vous en remercie encore

Le second problème a été de sauvegarder l'état des fenêtres à la fermeture de l'application.

J'avais fait un truc qui marchait mais j'étais assez lucide pour me rendre compte que c'était tarabiscoté asynchrone et merdique ....

Bacelar m'en a fait la remarque, je m'y attendais !!

Depuis j'ai amélioré, j'ai viré les timers inutiles et rendu la fermeture synchrone en passant par "Unregister" ..

En ce moment j'étudie comment faire ça de façon plus propre en créant une couche métier ...

Donc je suis en train d'apprendre à faire des threads en C++/CLI ...

Le problème présent est résolu et grâce à Bacelar et vous même j'ai appris à manipuler les Dictionnary et leurs clefs

Merci encore

Bonne soirée

[Mat.M]

Désolé, Le problème n'a jamais été au niveau de l' "Activate" .

Medinoc a me semble-t-il donné la bonne solution , je n'ai pas trop pigé ton problème qui semble sacrément tarabiscoté et compliqué...

Le second problème a été de sauvegarder l'état des fenêtres à la fermeture de l'application.

??
L'état des fenêtres ? Si tu sauvegardes un Handle de fenêtre à la fermeture de l'application il sera invalide par la suite on ne peut sauvegarder que les positions écran des fenêtres
Tout cela me semble compliqué
Ensuite encore une fois il ne faut pas gérer des threads inutilement ça va ralentir l'application

Je suis extrêmement circonspect sur la nécessité de cette usine à gaz.
.

on est au moins 2

[jlg_47]

L'état des fenêtres ? Si tu sauvegardes un Handle de fenêtre à la fermeture de l'application il sera invalide par la suite on ne peut sauvegarder que les positions écran des fenêtres

Je ne vois pas où est le problème à vouloir sauvegarder l'état complet d'une fenêtre au moment où on la ferme de façon à ce qu'elle s'ouvre dans le même état la fois suivante.

C'est tout ce que je voulais faire et je n'avais pas pensé à utiliser Unregister pour faire ça ... Maintenant cela marche nickel sans usine à gaz !!

Merci à tout le monde.