Version imprimable
Bonjour,
Dans mon appli, je garde en mémoire différentes fenêtres que je montre (showdiag) et que je masque (hide).
En mode debogage dans visual studio, lorsque je clique sur le bouton Hide (me.hide), cela masque non seulement la fenêtre enfant mais cela masque aussi la fenêtre principale qui se réduit dans la barre des tâches.
Je l'ai aussi constaté après un déploiement, mais ponctuellement.
Est-ce un bug ? Une erreur de ma part ?
Un des problèmes je crois est que tu utilises ShowDialog.
Ce showdialog affiche ta nouvelle fenêtre, mais en plus "normalement" elle empêche le retour sur la fenêtre appelante tant que celle-ci ne s'est pas refermé... Il y a un ordre de couche en quelque sorte.
Un simple Show devrait suffire.
sinon tu peux essayé de mettre la propriété TopMost a la fenêtre que tu veux afficher... elle sera au dessus de toute les autres.
Effectivement, avec Show j'évite le problème.
Cependant, ca m'ennuie beaucoup que l'utilisateur puisse avoir accès à la fenêtre parente et à la fenêtre fille en même temps. Topmost ne règle pas ce souci.
Hide et showdialog ne seraient-ils pas vraiment compatible ?
Pour tout te dire.... La "Bonne Méthode" serait de créer ta fenêtre au moment ou tu en as besoin.
Faire un ShowDialog, et fermer la fenêtre.
Si ta fenêtre contient des infos que tu souhaites conserver.... tu peux utiliser une structure, ou mieux une classe. Si tu as besoin de conseil à ce propos, n'hésite pas.
Et oui, c'est bien pour conserver mes variables que je garde mes fenêtres en second plan. Je sens qu'il va effectivement falloir que je change de méthode.
Trop de soucis en tout genre avec ce hide.
Donc :
- à l'ouverture, je lis les paramètres stockés dans une classe ou structure,
- à la fermeture j'écris dedans.
Si c'est bien ça, c'est simple sur le principe mais c'est un peu lourd pour la maintenance du code non ?
Non, au contraire.
Au début de ton programme, tu créer ton objet avec ta classe, tu l'instances avec les valeurs que tu veux.
Après, deux solutions:
-> (changement immédiat donc sans sauvegarde explicite ni annulation) Quand tu veux afficher ta fenêtre.... Et bien tu vas chercher les valeurs dans ton objet. Si l'utilisateur change quelque chose dans cette fameuse fenêtre, en même temps tu changes la valeur dans ta classe. Pas besoin de sauvegarde a la fermeture.
-> Sinon, (si tu veux que l'enregistrement se confirme ou puisse s'annuler). A ce moment, a l'ouverture de ta fenêtre tu créer un objet2 avec la même classe. tu fais un objet2=objet. Et a la fin, si l'utilisateur veut sauvegarder tu fais objet=objet2. Si l'utilisateur annule... il suffit de fermer la fenêtre et c'est réglé.
Dans les deux cas, ça prends pas beaucoup de ligne !
Merci pour tes précisions.
Par contre, je réponds plus tard : il faut que je pige et que je teste.
A bientôt.
Si je peux te dire une chose, si tu veux utiliser Show() plutot que show dialog, mais que ton user n'ai pas acces a ta fenetre precedente, il suffit de mettre cette fenetre enJuCode:Enabled=false
Et bien je ne suis pas sûr d'avoir bien compris les méthodes de mactwist69.
Solution 1 :
Cela veut-il dire que je modifie ma classe en fonction d'une instance de cette classe ? 8OCitation:
-> (changement immédiat donc sans sauvegarde explicite ni annulation) Quand tu veux afficher ta fenêtre.... Et bien tu vas chercher les valeurs dans ton objet. Si l'utilisateur change quelque chose dans cette fameuse fenêtre, en même temps tu changes la valeur dans ta classe. Pas besoin de sauvegarde a la fermeture.
Solution 2 :
Concernant cette solution, on définit une sorte de copie de notre fenêtre en fait. Mais où est déclaré cette copie ?Citation:
-> Sinon, (si tu veux que l'enregistrement se confirme ou puisse s'annuler). A ce moment, a l'ouverture de ta fenêtre tu créer un objet2 avec la même classe. tu fais un objet2=objet. Et a la fin, si l'utilisateur veut sauvegarder tu fais objet=objet2. Si l'utilisateur annule... il suffit de fermer la fenêtre et c'est réglé.
Si je la déclare dans la fenêtre parent, je n'y ai pas accès dans la fenêtre enfant : je ne peux pas rappatrier mes données.
Si je la déclare dans la fenêtre enfant, je la détruis à la femeture de cette fenêtre : j'ai tout perdu.
Dans un module ?
Concernant Julien :Ca devrait effectivement fonctionner. Je vais voir.Code:Enabled=false
Bonjour,
la solution de macTwist me parait pas mal.
Ta sauvegarde est dans la classe parent.Citation:
Solution 2 :
Citation:
-> Sinon, (si tu veux que l'enregistrement se confirme ou puisse s'annuler). A ce moment, a l'ouverture de ta fenêtre tu créer un objet2 avec la même classe. tu fais un objet2=objet. Et a la fin, si l'utilisateur veut sauvegarder tu fais objet=objet2. Si l'utilisateur annule... il suffit de fermer la fenêtre et c'est réglé.
Concernant cette solution, on définit une sorte de copie de notre fenêtre en fait. Mais où est déclaré cette copie ?
Si je la déclare dans la fenêtre parent, je n'y ai pas accès dans la fenêtre enfant : je ne peux pas rappatrier mes données.
Si je la déclare dans la fenêtre enfant, je la détruis à la femeture de cette fenêtre : j'ai tout perdu.
Dans un module ?
Tu la passes en paramètres de la création de ta fenêtre dialogue.
Tu modifies ton objet dans ta fenêtre.
A la fermeture, tu envoies un event avec ton objet.
Ton parent doit avoir une méthode qui récupère l'event.
Classe parent :
Classe de ton dialogue :Code:
2
3
4
5
6
7
8
9
NB : Ce n'est peut-être pas le code exact, mais cela peut te donner une idée de la solution.Code:
2
3
4
5
6
7
8
9
10
11
12
C'est ça, la solution de cougarg est exacte... Cela dis, tu le présente de manière un peu compliqué (en rajoutant les addhandler etc), il ne faudrait pas décourager notre amis !! :roll:
Et tu n'as pas introduit le fait de pouvoir annuler... Je te mets donc une version simplifié:
Ta Classe:
Code:
2
3
4
5
6
7
8
9
10
11
12
13
Ta fenêtre principale:
Ta fenetre qui "modifie" ta voiture: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
34
35
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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Sinon, La première solution serait:
Code:
2
3
4
5
6
7
8
9
10
11
12
13
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
et ta fenetre :
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
34
35
36
37
38
39
40
41
Bon, c'est code sont loin d'être complet et nickel... C'est vraiment pour simplifié le principe.... Parce que j'imagine que tu gères pas tout encore...
Vois si tu comprends l'idée... Mais si tu peux, essaie de voir le code de Courgag. :ccool:
Merci pour vos contributions, c'est très intéressant.:ccool:
Sans vouloir vexer cougarg, je vais commencer par la solution de mactwist69.
Je commence donc avec ce qui me semble le plus à ma portée.:oops:
J'ai quelques questions et remarques :
Solution 2 :
Là, je ne pige pas :
Si on travaille bien sans Hide mais avec close ou dispose, quand Mafenetre est fermée je pensais qu'on ne pouvait plus l'utiliser.:?Code:
2
3
4
5
6
7Dim MaFenetre as New MaFenetre_affiche_voiture (MaVoiture) MaFenetre.showdialog() if MaFenetre.DialogResult = OK MaVoiture = MaFenetre.MaVoiture End If
Utilises-tu le fait que lorsqu'un formulaire est fermé, il n'est pas encore détruit ?
C'est justement ce que je voulais éviter avec le Hide.
Sinon, une question bête :
Pourquoi :
Et non pas :Code:
2
3
4
5
6
7
8
9
10
Solution 1 :Code:
2
3
4
5
Je comprends assez bien cette solution. Je me demandais simplement : si je ferme la fenêtre principale (form_main) et que je la recrée ensuite, j'ai perdu ses valeurs par défauts ?!
Comme je modifie la classe, j'aurai toujours form_main avec les dernières variables saisies dans form_enfant ?
Pour le vérifier j'ai testé avec fen_meregrand / fen_mere / fen_enfant mais là le passage des variables ne fonctionne plus du tout de fen_enfant à fen_mere. Bizarre.
Je ne désespère pas et continue à regarder ça.
Salut pour ta question par rapport a l'instanciation. Il est fortement deconseiller de faire une new (donc instancier) un object de ta classe a la declaration des variables. Le mieux est de ;ettre tes variables a leurs valeurs par defaut dans le New. Dans tout les cas cette fonction est appellee donc pas de soucis
-> En fait, comme on fait de la Programmation objet, MaFenetre_affiche_voiture est une classe. En l'occurrence une classe qui contient un formulaire. Pour afficher ta fenêtre il faut donc créer un obet et l'instancié avec la classe. C'est ce que tu fais quand tu utilises un New. Donc a partir de ce principe... Tu peux créer ta fenêtre autant de fois que tu veux. Et c'est la le principe. Par exemple, dans ta fenetre principale tu as une liste d'élément, si tu souhaites que quand l'utilisateur sélectionne un élément l'affiche dans ta fenetre, et bien tu te créer un objet. Et tu la referme avec un dispose quand l'utilisateur a finis.Citation:
Envoyé par yann_DZ
Et pour garder en mémoire les infos qui était afficher dans ta fenetre, tu utilises une autre classe (MaVoiture) Qui elle, est créer dans ta fenêtre principale (et comme par principe ta fenetre principale ne se ferme que quand ton logiciel est arreter...) alors tu gardes en mémoires les infos tout le temps)
-> tu te trompe a ton grand bonheur, Quand tu déclare une variable local avec un Dim. Si quelques lignes après du fais un close() ou un dispose(), la mémoire est liberré, tu ce qu'il y avait dedans est effacé... D'où notre besoin d'utiliser une classe (MaVoiture) pour faire l'intermédiaire.Citation:
Envoyé par yann_DZ
garciajulien a raison, moi j'avoue avoir appris a programmé comme ça. Je déclare mes variables global en propriétés. J'instancie dans le New(). Je pense également que c'est le "best practice".Citation:
Envoyé par yann_DZ
->Ben en principe, quand tu créer un logiciel... Elle démarre sur ta fenêtre principale... et si tu ferme ce formulaire ben ton logiciel s'arrête. Donc forcement a ce moment, tout ce qu'il y a dans tes propriétés et classe se vide. (comme quand tu fais un close() d'une variable local)Citation:
Envoyé par yann_DZ
-> c'est pas ta classe que tu modifies c'est l'objet. je te reprend ton exemple:Citation:
Envoyé par yann_DZ
Tu as Fenetre_grand_mere : c'est ta fenêtre principale, ton logiciel démarre dessus, et contient une liste de voiture.. tu as une fenêtre mère, avec un formulaire, qui affiche toutes tes infos voiture.
Dans ta fenetre principale tu declare un obet de Type (= classe) voiture:
-> tu declare justement ta variable en Public pour pouvoir l'utiliser a partir de n'importe quem autre fenetre.Code:Public MaVoiture as Voiture
Bon dans le New de ta fenetre GRand_mere (donc qui se déclenche au premier lancement de ton logiciel), tu fais:
La ça créer ton objet MaVoiture en mémoire, c'a y'est tu peux l'utiliser.Code:MaVoiture = New Voiture
Pour l'appeler d'une autre fenêtre comme la fenêtre mère.:
Cette ligne de code peut être appeler partout.Code:Fenetre_grand_mere.MaVoiture.immatriculation = 10
Voici une réponse bien étoffée. Il y a de quoi faire.
Mais, sans vouloir vexer mactwist69, je m'étonne sur le contenu de ce qui est écrit.
1- Instanciation dans le sub new.
(Je dis vous car cela concerne julien et mactwist69.)
Vous me dites que c'est la meilleure des méthodes et n'étant pas informaticien de formation, je suis vraiment prêt à vous croire.
Cependant, je ne compte plus le nombre de livres, de sources et de discussions sur ce site ou je vois des instanciations n'importe où (surtout en dehors du sub new !).
Personnellement, je fais beaucoup de math. Je suis bien incapable de compter le nombre d'objets mathématiques qui sont crées dynamiquement dans les processus itératifs mes applications !
Je pense que je dois vraiment mal comprendre ce que vous indiquez. :?
2- Solution 2.
Je sais très bien ce qu'est une classe (à mon humble niveau bien sûr) et je comprends parfaitement l'utilité de créer une copie de Ma voiture dans ma fenêtre principale car une fois la fenêtre enfant fermée, bye bye les données.
C'était la cause initiale de cette discussion car jusqu'à présent, aulieu de fermer le fenêtre enfant, je la cachais, récupérais les données puis la fermais enfin.
Je reviens sur ton code :
J'insiste peut-être lourdement mais si Mafenetre est fermée avec close, je ne peux pas écrire :Code:
2
3
4
5
6
car MaFenêtre n'existe plus !!!!!!!!!!Code:
2
3
Je crois qu'il arrive que cela fonctionne tout de même car si la fenêtre est fermée, elle n'est pas forcemment détruite avec le machin truc ésotérique qui s'appelle le garbagecollector.
Dans l'idée de la solution2, je propose ceci :
Voilà, je serai bien content d'avoir quelques commentaires.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
3- Solution 1.
Ok, j'ai compris l'astuce et mon erreur d'interprétation.
Par contre, je ne vois pas trop l'intérêt : c'est tout comme si je déclarais mes variables dans un module afin qu'elles soient accessible partout !
Voila, j'en ai fini pour ce soir.
Merci encore et bonne soirée à tous.
Hier soir, j'ai fini ma soirée en me disant qu'un truc ne tournait pas rond dans mon dernier message. :cfou:
A propos de l'instanciation dans le Sub New, vous parliez d'objets spécifiques : ceux qui ont des portées globales ...
Mea culpa.
Cependant, si c'est la meilleure méthode, quelqu'un peut-il en expliquer juste un peu la raison ?
Pour éviter les problèmes sur le Hide de la Form2, on pourra en conception créer dans Form2 un panel Form2.GlobalPanel (Dock=Fill) qui contient tout les controls de la forme.Citation:
Et oui, c'est bien pour conserver mes variables que je garde mes fenêtres en second plan. Je sens qu'il va effectivement falloir que je change de méthode.
Avant le premier ShowDialog() de la Form2 : Créer la Form2.
A la fin des ShowModal() avant de fermer/supprimer la forme, on fait:
Quand on veut refaire un ShowDialog() de la Form2, on crée dynamiquement une forme vide et :Code:
2
Code:SaveGlobalPanel.Parent=NewForm
C'est pas mal ta technique pour garder la fenêtre en mémoire.
Sinon, J'insite Yann_DZ, je te montre les évènements dans l'ordre:
Fenetre_mere:
Fenetre Fille:Code:
2
Fenetre_mere:Code:me.dialogresult= ok
Quand tu reviens un dialogresult, Ca ne ferme pas ta fenetre,Code:
2
3
4
5
donc pas la memoire, donc tu peux encore copié ton objet
Et c'est pour ca que APRES tu fais MaFenetre.dispose !
Bonsoir, désolé pour le contre-temps.
D'accord, ok, ok, ok ... j'ai pigé.
Avec un peu de retard comme d'habitude.
En fait je n'utilise jamais les dialogresult.
Mactwist69 vient de m'en démontrer l'intérêt.
Je n'oublierai pas ! ;)
Je marque comme résolu.
Merci à tous les intervenants.
A+