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
Version imprimable
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 :
par :Code:formulairesOuverts = gcnew Dictionary <int, Form2^>;
Mais pourquoi? et est ce correct?Code:Dictionary <int, Form2^>^ formulairesOuverts = gcnew Dictionary <int, Form2^>;
A l'ex�cution, �a se plante sur :
avec le message :Code:if(!formulairesOuverts->ContainsKey(clef))
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�.
doit avoir �t� fait avant.Code:formulairesOuverts = gcnew Dictionary<int, Form2^>;
Citation:
Envoy� par bacelar
Mais
le compilo n'en veut pas !!Code:formulairesOuverts = gcnew Dictionary<int, Form2^>;
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� :
par :Code:formulairesOuverts = gcnew Dictionary<int, Form2^>;
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.
Cela fonctionne parfaitement quand je ferme la fen�tre fille sans fermer l'application m�re.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
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
J'ai volontairement mis 3 secondes entre la fermeture de chaque fen�tre pour v�rifier le fonctionnement.Code:
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
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 :
Est ce que FormFille_Close() va s'ex�cuter imm�diatement c'est � dire avant que la boucle "for each" soit finie ?Code:formulairesOuverts[SelectedItem]->FormFille_Close();
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.
Bonjour Bacelar et merci encore une fois pour votre aide pr�cieuse ...Citation:
Envoy� par bacelar
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 ...
Pour vous expliquer ce que je veux faire, je prends un exemple simple:Citation:
Envoy� par bacelar
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 ?
une interface MDI serait plus appropri�e ; est-ce le cas ?Citation:
Envoy� par 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!
Citation:
Envoy� par M�dinoc
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
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
??Citation:
Envoy� par 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
Tout cela me semble compliqu�
Ensuite encore une fois il ne faut pas g�rer des threads inutilement �a va ralentir l'application
on est au moins 2 :mrgreen:Citation:
Envoy� par bacelar
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.Citation:
Envoy� par Mat.M
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: