C++/CLI : gestion de fenêtres filles à partir d'une fenêtre mère

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 :D

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

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...

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.

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:

---

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

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.

Citation:

---

Envoyé par bacelar

Pourquoi passer par un singleton.

---

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

Citation:

---

Envoyé par bacelar

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.

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

Bonjour,

Aujourd'hui j'ai trouvé 5 minutes pour me replonger sur ce problème.

J'ai créé une Form1 puis une seconde Form2.

Dans la forme 1 j'ai ajouté un bouton que j'ai associé à ce bout de code:

Code:

---

1 2 3 4

i++; Form2^ f2 = gcnew Form2(); f2->Show (this); f2->clef = i;

---

i est un entier.

Dans Form2 j'ai rajouté une variable :

Code:

---

public: int clef;

---

et une textbox + un bouton associé à:

Code:

---

1 2 3 4

private: System::Void button1_Click(System::Object^ sender, System::EventArgs^ e) { textBox1->Text = clef.ToString(); }

---

Quand j'ouvre plusieurs fenêtres Form2, je visualise bien 1, 2, 3, etc ... dans la textbox. Donc mes fenêtres fille récupèrent bien leur clef respective.

Mais je ne vois toujours pas comment on peut réactiver une fenêtre déjà instanciée ...

Exemple : je sais que la fenêtre qui a la clef n° 3 existe déjà, comment puis je la réveiller?

De même si je ferme la fenêtre 3 comment avertir la Form1 de cet évènement?

Bonne soirée.

Citation:

---

Envoyé par bacelar

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

Code:

---

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

---

Citation:

---

Envoyé par Médinoc

Code:

---

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

---

---

Bonjour Médinoc,


Merci.
Vu mon niveau c'est un peu laconique, mais cela m'a servi à découvrir des choses.

J'ai découvert qu'il existe une propriété qui s'appelle OwnedForms (VOIR ICI)

Mais je ne comprends pas bien ...

Je pense qu'il faut créer une Array (peut-être ce que vous appelez Dictionnary?), mais où et comment la déclarer? c'est toujours mon problème. :aie:

Ensuite je pense qu'à chaque création de Form il faut faire un AddOwnedForm pour mettre la Form dans le dictionnaire.

Est ce que je suis sur la bonne voie?

Bonne journée

Je ne connaissais pas les Owned Forms, je voulais juste te dire de simplement mémoriser les formulaires que tu crées dans une variable membre, plutôt que chercher à les "retrouver" quand tu en as besoin.

Citation:

---

Envoyé par Médinoc

Je ne connaissais pas les Owned Forms, je voulais juste te dire de simplement mémoriser les formulaires que tu crées dans une variable membre, plutôt que chercher à les "retrouver" quand tu en as besoin.

---

C'est comme cela que je l'avais compris ..

J'ai réussi à faire ce que je voulais, mais je ne sais pas si la méthode utilisée est très professionnelle. :roll:

J'ai fait une List de mes Form...

Code:

---

1 2 3 4 5 6 7 8 9 10 11

private: List<Form^> ^ mes_formes; . .   mes_formes = gcnew List<Form^>; . . Form2 ^f2 = gcnew Form2(); mes_formes->Add(f2); f2->Show(this);

---

Ensuite en faisant :

Code:

---

mes_formes[i]->Focus();

---

J'arrive à redonner le focus à la forme qui m'intéresse :D

J'arrive aussi à la modifier (taille, titre, etc ...)

Maintenant si cette méthode tient la route, il faut que je trouve comment une Form fille peut alerter la Form mère du fait qu'elle a été fermée par l'utilisateur.

Bonne journée.

Tu écoutes l'événement FormClosed...

Citation:

---

Envoyé par Médinoc

Tu écoutes l'événement FormClosed...

---

Mais comment et avec quoi?

Il faudrait un contrôle dans Form1 qui s'active lors d'un FormClosed d'une des Forms :marteau:

Je ne vois pas du tout comment faire ça.

Au fait tu ne m'as pas dit si ma solution avec la List est une solution acceptable.

Bonne soirée

A oui, je n'avais pas pensé aux events publiés par les Formulaires.
Ca simplifie le code de gestion de cette fonctionnalité mais l'utilisation des delegates en C++/CLI pour une personne venant du C++ standard, c'est loin d'être naturel.

L'utilisation de la liste, c'est la bonne voie. Le problème, c'est que vous devez utilisez un identifiant et non un indice. Si vous voulez ouvrir une Form fille pour l'item de clef "2" sans ouvrir l'item de clef "1", vous avez un problème avec une list, car il aura plein de trou.
On utilise donc une autre structure qui associe une clé à un objet, c'est le "Dictionary<int, Form2^> " de Médinoc.
http://msdn.microsoft.com/en-us/libr...v=vs.110).aspx
C'est comme votre liste, sauf que les objets ne sont pas stockés les uns derrière les autres, mais associe une clé à un objet.

en ajoutant une propriété public m_cle à votre classe de formulaire secondaire, le code, avec utilisation de delegate sur l'event FormClosed.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

private: Dictionary<int, Form2^> formulairesOuverts; . .   formulairesOuverts = gcnew Dictionary<int, Form2^>; . . . if(!formulairesOuverts->ContainsKey(clef)) { formulairesOuverts->Add(clef,gcnew Form2(clef)); ((Form2^)(formulairesOuverts[clef]))->FormClosed += gcnew System::Windows::Forms::FormClosedEventHandler(this, &Form1::Unregister); } formulairesOuverts[clef]->Show();   ... private: void Unregister(System::Object^ sender, FormClosedEventArgs^ e) { if(formulairesOuverts->ContainsValue((Form2^)(sender))) { formulairesOuverts->Remove(((Form2^)(sender))->m_cle); } }

---

Mais je pense que l'utilisation des delegates va poser des problèmes de threading.

Donc, un approche plus safe est de faire un appel à la méthode Unregister depuis le formulaire secondaire, il suffit d'utiliser le champ Owner du formulaire pour retrouver le formulaire principale et de le caster en Form1.

P.S.:"OwnedForms", c'est une mauvaise voie (ou très indirecte, mais tout les chemins mènent à Rome :aie:).

J'ai oublié de dire que souvent les contrôles .NET multi-lignes ont des propriétés avec des Noms type "Tags" pour chaque ligne qui sont souvent utilisées pour stocker ces références.

Dans notre cas, cela implique que nous n'aurions plus de champ dictionnaire "formulairesOuverts", mais que l'ont stockerait les références directement dans le champ "Tags" de la ligne du control.

Le cast n'est pas nécessaire sur cette ligne:

Code:

---

((Form2^)(formulairesOuverts[clef]))->FormClosed += gcnew System::Windows::Forms::FormClosedEventHandler(this, &Form1::Unregister);

---

Bonsoir et merci à tous deux ...

Bon c'est vrai que je suis un peu (beaucoup) dans le brouillard, ..

J'ai essayé de compiler le bout de code de Bacelar, ..

le compilateur me jette sur :

Code:

---

if(!formulairesOuverts->ContainsKey(clef))

---

avec le message :

Code:

---

error C2819: type 'System::Collections::Generic::Dictionary<TKey,TValue>' does not have an overloaded member 'operator ->'

---

il me jette aussi sur :

Code:

---

formulairesOuverts->Add(clef,gcnew Form2(clef));

---

avec le message :

Code:

---

error C2232: '->System::Collections::Generic::Dictionary<TKey,TValue>::Add' : left operand has 'class' type, use '.'

---

Et il me jette aussi dans Unregister avec des messages similaires

J'ai essayé divers trucs mais toujours les erreurs .. je ne comprends parce que si on regarde les exemples de Microsoft cela paraît correct ..

Bonne soirée

Désolé, il y avait une erreur dans la ligne que j'ai proposée: Il manquait un chapeau:

Code:

---

Dictionary<int, Form2^>^ formulairesOuverts;

---

Merci ...

ça se compile maintenant ...

Il faudrait que j'arrive à bien assimiler ces notations baroques avec ces ^ ..

Bon je regarde ce que je peux faire de ce que vous m'avez appris et je vous tiens au courant.

Bonne soirée

Ah! j'ai oublié de dire que pour que ça compile j'ai dû changer :

Code:

---

formulairesOuverts = gcnew Dictionary <int, Form2^>;

---

par :

Code:

---

Dictionary <int, Form2^>^ formulairesOuverts = gcnew Dictionary <int, Form2^>;

---

Mais pourquoi? et est ce correct?

A l'exécution, ça se plante sur :

Code:

---

if(!formulairesOuverts->ContainsKey(clef))

---

avec le message :

An unhandled exception of type 'System.NullReferenceException' occurred in essai_forme.exe
Additional information: La référence d'objet n'est pas définie à une instance d'un objet.


Bonne soirée

A un caractère ^ du Nirvana.:aie:

formulairesOuverts doit être "nullptr" à ce moment là.

Code:

---

formulairesOuverts = gcnew Dictionary<int, Form2^>;

---

doit avoir été fait avant.

Citation:

---

Envoyé par bacelar

A un caractère ^ du Nirvana.:aie:

formulairesOuverts doit être "nullptr" à ce moment là.

Code:

---

formulairesOuverts = gcnew Dictionary<int, Form2^>;

---

doit avoir été fait avant.

---

Mais

Code:

---

formulairesOuverts = gcnew Dictionary<int, Form2^>;

---

le compilo n'en veut pas !!

Il me jette avec ça :

error C2440: '=' : cannot convert from 'System::Collections::Generic::Dictionary<TKey,TValue> ^' to 'System::Collections::Generic::Dictionary<TKey,TValue> ^'


Et pour moi c'est comme si on me disait que 2 ne vaut pas 2 !!



Bonne soirée

>Et pour moi c'est comme si on me disait que 2 ne vaut pas 2 !!

Bin non, c'est un template.
C'est comme : "x+y=z+w quelque soit x,y,z et w" est là c'est faux. :aie:

Le message d'erreur doit indiquer les types effectifs pour TKey et TValue.
Il doit avoir au moins un type différent à gauche et à droite.

Merci ça marche :ccool:

J'ai remplacé :

Code:

---

formulairesOuverts = gcnew Dictionary<int, Form2^>;

---

par :

Code:

---

formulairesOuverts = gcnew Dictionary<int, Form^>;

---

J'ai rajouté une Textbox dans Form1 pour afficher la clef de la fenêtre qui est fermée au moment de l'appel à Unregister et on récupère bien la clef :D

Merci mille fois à Médinoc et à vous !!!

Bonne journée ..

En remplaçant Form2 par Form, vous avez assoupli les règles de typage.

Il faut toujours faire ces assouplissements avec beaucoup de précaution car vous empêchez indirectement le compilateur de vous aidez.

Cet assouplissement n'est pertinent que si vous voulez insérer d'autres types de formulaires que Form2 dans le dictionnaire "formulairesOuverts".

Sinon, c'est plutôt le ou les types déduit(s) de chaque coté de l'expression avec le "=" en erreur qu'il faut vérifier et corriger.

Merci encore.

C'est corrigé, j'avais oublié le 2 dans la déclaration des variables.

Bonne journée.

Je rajoute une petite précision ...

Vu qu'à chaque ouverture d'une fenêtre fille, je lui donne un nom ... J'ai utilisé ce nom en guise de clef .. donc au lieu de passer un int je passe un String^ et cela fonctionne très bien !!

Merci encore pour votre aide précieuse

Bonne journée

Bonjour,


Je reviens sur ce sujet car j'ai un peu compliqué les choses et j'ai de nouveau un petit souci.

J'ai rajouté un bout de code dans l'application "fille" qui, à la fermeture d'une fenêtre fille, enregistre l'état d'un objet dans un fichier.

Code:

---

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

private: System::Void Form2_FormClosing(System::Object^ sender, System::Windows::Forms::FormClosingEventArgs^ e) { if (Stop_flag == false) { e->Cancel = true; FormFille_Close();} }   public: Void FormFille_Close() { etape = 0; timerArret->Enabled = true; }   private: System::Void timerArret_Tick(System::Object^ sender, System::EventArgs^ e) { switch (etape) { case 0: etape++; Ecrire_Fichier(); break; case 1: timer->Enabled = false; Stop_flag =true; Close(); break; default: break; } }

---

Cela fonctionne parfaitement quand je ferme la fenêtre fille sans fermer l'application mère.

J'ai déclaré FormFille_Close() public pour qu'à l'arrêt de l'application mère, je puisse fermer successivement les fenêtres filles encore ouvertes et sauver l'état de l'objet associé.

Donc à l'arrêt de l'application j'ai de nouveau un bout de code qui ferme les fenêtres les unes après les autres en appelant FormFille_Close()

J'utilise une méthode similaire à celle de la fermeture de la FormFille en utilisant un timer

Code:

---

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 29 30 31 32 33

private: System::Void timerArret_Tick(System::Object^ sender, System::EventArgs^ e) { switch (etape) { case 0: ProgressBar->Value++; j= 0; etape++; if (n_formulaires == 0) etape++; // si aucun formulaire ouvert on saute l'étape suivante break; case 1: // on ferme les formulaires ouverts ProgressBar->Value++; int k = 0; for each (KeyValuePair<String ^, Form2^> ^ formulaire in formulairesOuverts) { if (k==0) // on ferme le premier formulaire trouvé { SelectedItem = formulaire->Key; formulairesOuverts[SelectedItem]->FormFille_Close(); // Note : à chaque fermeture le formulaire est supprimé par lui-même par Unregister } k++; } j++; if (j == n_formulaires) etape++; // quand tous les formulaires sont fermés on passe à la dernière étape break; case 2: Stop_flag = true; timerArret->Enabled = false; Close(); break; default: break; } }

---

J'ai volontairement mis 3 secondes entre la fermeture de chaque fenêtre pour vérifier le fonctionnement.

Chaque fenêtre est donc bien fermée au moment voulu, mais l'état n'est pas sauvegardé laissant supposer que l'écriture du fichier par l'application fille ne se fait pas :aie:

Je n'arrive pas à voir ce qui différencie une fermeture manuelle d'une fenêtre fille (cas qui fonctionne parfaitement :D ) d'une fermeture en fin d'application (cas qui ne fonctionne pas)

Il y a sûrement une façon plus simple et plus astucieuse pour faire ça, mais cela ne me dit pas pourquoi ça ne marche pas comme je voudrais !!

En fait je me rends compte qu'il y a beaucoup de choses que je ne sais pas ..:mrgreen:

Par exemple quand je fais :

Code:

---

formulairesOuverts[SelectedItem]->FormFille_Close();

---

Est ce que FormFille_Close() va s'exécuter immédiatement c'est à dire avant que la boucle "for each" soit finie ?

A quel moment "Unregister" va être exécuté?

Merci à ceux qui pourront m'aider

Bonne journée

Euh! Bon !!

Désolé d'avoir déranger ceux qui m'auraient lu ...

J'ai enfin trouvé la raison à ce truc sur lequel je butte depuis plus de 24 heures :oops:

C'est juste que chaque fenêtre en se fermant réécrit le fichier tel qu'elle l'a reçu en y ajoutant les modifications de son propre objet ... du coup elle efface les modifications faites dans les objets attachés aux autres fenêtres ..

J'ai résolu le problème en relisant le fichier avant de l'écrire de façon à ce que chaque modification soit bien prise en compte.

Mais je reste preneur pour toute méthode plus simple pour faire ce genre de chose. :D

Bonne journée

>J'ai volontairement mis 3 secondes entre la fermeture de chaque fenêtre pour vérifier le fonctionnement.
Oui, mais c'est combien de secondes entre l'étape 0 et 1 dans les formulaires enfants ?

La différence de l'un, c'est qu'il arrête de thread principal du processus et donc arrête aussi les timers et les autres threads.

Je trouve que votre architecture est horriblement complexe avec toute ces actions asynchrones avec ces timers dans tous les coins.

Il y a une grosse faille dans votre algorithme, c'est l'endroit où ou vous faites "j++".
Vous faites cela juste après l'appel de "FormFille_Close", il faudrait le faire dans le Close de la fenêtre fille, donc via une fonction de callback vers le formulaire principal. (donc une architecture encore plus complexe et couplée)

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

Vous nous donnez votre "solution" à une problème, mais vous ne nous donnez pas le but de tout cela, donc difficile de vous donnez LA solution pour implémenter votre fonctionnalité.

La concurrence sur l'accès au fichier, l'ordonnancement de la sérialisation, la maintenabilité en cas de changement de couche graphique, etc... sont des chose que votre solution vas bloquée.

Si vous découpez votre application entre la couche graphique avec ses formulaires, et une couche métier/données qui sera en charge de conserver les données et d'appliquer les règles métiers, vous aurez une application bien plus simple à faire évoluée.
Dans ce cas, la sérialisation des données (enregistre l'état d'un objet dans un fichier) sera bien plus simple, car la couche métier à tout les objets et peut les sérialisées quand il veut, et de manière ordonnée.

Citation:

---

Envoyé par bacelar

Si vous découpez votre application entre la couche graphique avec ses formulaires, et une couche métier/données qui sera en charge de conserver les données et d'appliquer les règles métiers, vous aurez une application bien plus simple à faire évoluée.

---

Bonjour Bacelar et merci encore une fois pour votre aide précieuse ...


Je pense effectivement à découper mon application en une couche métier/données et une couche graphique ... Il faudra que je le fasse tôt ou tard

J'ai longtemps programmé avec des systèmes temps réel multi-tâches et je savais faire ça très bien .. Mais c'était au siècle dernier :D

En C++/CLI, je suis nul donc j'y vais pas à pas ...

Citation:

---

Envoyé par bacelar

mais vous ne nous donnez pas le but de tout cela, donc difficile de vous donnez LA solution pour implémenter votre fonctionnalité.

---

Pour vous expliquer ce que je veux faire, je prends un exemple simple:

Disons que mes objets sont des avions caractérisés par leur position, cap, vitesse, altitude, n°de vol, etc .... les objets sont sérializables et stockés dans un fichier...
Ils sont récupérés et stockés dans un dictionnaire dont la clef est le n°de vol

Ma Form1 permet de rajouter, modifier, supprimer des objets .... et de les visualiser dans une listview ...

en double cliquant un objet de la listview j'ouvre une fenêtre fille qui me donne accès à un avion avec lequel je peux jouer :D ...

En ouvrant plusieurs fenêtres je peux jouer avec plusieurs avions ...

Quand je ferme une fenêtre fille, je sauvegarde l'état de mon avion pour le retrouver la fois suivante ...

Et quand je ferme l'application je récupère l'état de chaque avion pour la prochaine cession.

Pour l'instant un avion est censé être immobile quand sa fenêtre est fermée...
Mais un jour ou l'autre je sais que j'aurais envie de le faire voler tout seul en background donc il me faudra bien cette couche métier/données ...

Bon dimanche

L'histoire de la solution mais pas le problème, tout ça, c'était pour le fait que vous attendiez après la fermeture de la fenêtre fille.

Mais l'exposé de votre but montre bien qu'une couche métier/donnée est indispensable. :mouarf:

A la fermeture de votre fenêtre fille, vous notifiez votre couche données sur les données directement, sans attendre.

Cette couche métier fera les actions nécessaires à la sauvegarde des données, de manière synchrone.

Je ne vois pas pourquoi ne pas faire cette sauvegarde de manière synchrone ?

Citation:

---

Envoyé par jlg_47

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 ?

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

Citation:

---

Envoyé par 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!

---

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 :lol:

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é :mrgreen: 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

Citation:

---

Envoyé par jlg_47

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é...

Citation:

---

Envoyé par jlg_47

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

Citation:

---

Envoyé par bacelar

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

---

on est au moins 2 :mrgreen:

Citation:

---

Envoyé par Mat.M

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.

C'est clair que si c'est fait de manière synchrone, c'est bien plus simple.

Nous venons d'éradiquer une usine à gaz, next. :aie: