Discussion :

[TaPuZ]

Bonjour.
Je sais qu'en ce moment Pussy-Pouce poste un sujet similaire, mais je rencontre un problème depuis plusieurs jours sur la gestion des fenêtres filles, et pas forcément au même niveau de compréhension. Et j'avoue que je ne trouve pas de solution (du moins à ma portée) sur la toile, et/ou, que les solutions rencontrées ne me résolvent pas mon problème :
C'est donc qu'il y a une donnée fondamentale, et certainement triviale qui m'échappe.

Voici donc mon but :

J'ai une MainForm. Dedans, un menu. Et quand je clique sur un item, je veux qu'il ouvre une FormFille.

Mon code :

Quand je clique sur mon item :

Code :

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

1
2
3
4
5
6
7
8
9
 
void ToolStripMenuItem3Click(object sender, System.EventArgs e)
		{
 
			this.Hide();
			FormFille FF = new FormFille();
			FF.MdiParent = this;
			FF.Show();
		}

Et ma FormFille :

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
 
 
using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
 
namespace NameSpaceLambda
{
	/// <summary>
	/// Description résumée de FormFille.
	/// </summary>
	public class FormFille : Form
	{
		/// <summary>
		/// Variable nécessaire au concepteur.
		/// </summary>
		private System.ComponentModel.Container components = null;
 
		public FormFille()
		{
			//
			// Requis pour la prise en charge du Concepteur Windows Forms
			//
			InitializeComponent();
 
			//
			// TODO : ajoutez le code du constructeur après l'appel à InitializeComponent
			//
		}
 
		/// <summary>
		/// Nettoyage des ressources utilisées.
		/// </summary>
		protected override void Dispose( bool disposing )
		{
			if( disposing )
			{
				if(components != null)
				{
					components.Dispose();
				}
			}
			base.Dispose( disposing );
		}
 
		#region Code généré par le Concepteur Windows Form
		/// <summary>
		/// Méthode requise pour la prise en charge du concepteur - ne modifiez pas
		/// le contenu de cette méthode avec l'éditeur de code.
		/// </summary>
		private void InitializeComponent()
		{
			System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(FormFille));
			this.SuspendLayout();
			// 
			// FormFille
			// 
			this.BackgroundImage = ((System.Drawing.Image)(resources.GetObject("$this.BackgroundImage")));
			this.BackgroundImageLayout = System.Windows.Forms.ImageLayout.Stretch;
			this.ClientSize = new System.Drawing.Size(584, 364);
			this.Name = "FormFille";
			this.Text = "Blablabla...";
			this.ResumeLayout(false);
		}
		#endregion
	}
}

Mon problème :

En cliquant sur l'item, pas d'ouverture de fenetre fille. Par contre si je glisse un MessageBox.Show dans le code de ma MainForm, bien entendu, celle-ci s'affiche.

La solution recherchée :

Avoir à chaque clic sur l'item, la fenetre qui s'ouvre.
Idéalement, qu'elle puisse ne s'ouvrir qu'une et une seule fois à la fois.

Merci d'avance de vous pencher sur mon pauvre cas...

[Kaidan]

Pourquoi tu appelles this.Hide() qui va cacher MainForm alors que tu veux afficher FF comme une fenêtre MDI de MainForm ? Concernant le fait de n'ouvrir qu'une seule fois la fenêtre, tu peux regarder du côté du pattern Singleton. Mais si ce que tu souhaites faire, c'est afficher une fenêtre modale, il va falloir utiliser ShowDialog() au lieu de Show().

[ctxnop]

Bonjour.
Premièrement, comme le dit Kaidan, il ne faut pas masquer ta fenêtre mère. Ça n'a pas de sens, puisqu'elle est la fenêtre principale de l'application et que la masquer reviens a dire que l'utilisateur ne pourra plus cliquer dans le menu a nouveau.

Concernant le fait qu'elle ne s'ouvre qu'une fois, oui, le design pattern du singleton est une très bonne solution. Mais vu que tu débutes, tu risque fortement d' absolument pas comprendre ce que tu codera en recopiant l'implémentation du Singleton.

Aussi, une solution plus simple serai :

Code csharp :

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
 
public partial classe MainForm
{
    private FormFille _fille;
    /* Le reste du code de ta classe */
    void ToolStripMenuItem3Click(object sender, System.EventArgs e)
    {
        if(_fille == null) // Si aucune fenêtre fille n'est instanciée
        {
            _fille = new FormFille();
            _fille.MdiParent = this;
            _fille.FormClose += FilleForm_FormClose; // Gère un évènement lorsque la fenêtre fille est fermée.
            _fille.Show();
        }
        else
        {
            _fille.Focus(); // Si une fenêtre fille existe déjà, on lui donne le focus.
        }
    }
 
    void FilleForm_FormClose(object sender, System.Windows.Forms.FormClosedEventArgs e)
    {
        _fille.FormClose -= FilleForm_FormClose; // Enlève le gestionnaire d'évènement
        _fille = null; // Efface le contenu de la variable afin de pouvoir instancier a nouveau une fenêtre fille au prochain click.
    }
}

C'est moins propre que le singleton, mais c'est plus facile a comprendre.

[TaPuZ]

Merci pour vos réponses.
Pour le This.Hide, effectivement, une boulette de ma part qui est restée :Je l'avais mis pour vérifier que les commandes passées dans cet endroit du code s'exécutaient bien.
Je sais, un test unitaire, ou du pas a pas, etc...
Mais bon, quand on est vieux et c.., c'est dur de ne pas rester cantonné à du concret!
Bref, je teste cela ce soir, et j'espère pouvoir étiqueter un tag "Résolu"!
Et si c'est le cas, je m'en vais illico chercher à comprendre ce qu'est le cingléthon (une sorte de collecte pour venir en aide aux cinglés, je suppose.. )
Merci encore.

A bientôt.
T@PµZ.

[TaPuZ]

Bonsoir.
Je sais que le double post est à bannir, et que la fonction EDIT existe...
Mais cela permet de "upper" mon message, car je viens de me rendre compte de quelque chose de singulier.

Dans le code que j'avais fait précédemment (qui est dans mon premier post), tout comme dans celui que vous m'avez cordialement fait, j'obtiens le même résultat.
Ce que je voyais au début comme un "rien ne se passe" n'est pas exact.
C'est comme si la fenêtre fille était apparue "masquée".
En réalité, je n'ai qu'une ligne de pixels (autant dire un cheveu), à la limite de mon menu.
Du coup presque invisible.
En positionnant ma souris dessus, une double flèche apparait, comme pour permettre l'agrandissement de ladite fenêtre. Mais je ne peux "redimensionner" que vers le haut, et non vers le bas. Et de toutes les manières, rien ne se voit.
Voilà pour la complainte de mes misères.
Sinon, j'ai bien compris l'exemple, et j'ai hâte d'en découdre avec les singletons.
Mais j'ai mon premier problème à résoudre d'abord...


A bientôt,
T@PµZ.


EDIT 1 :

(et oui, j'y viens... )

En agrandissant la mainform, et en jouant avec la ligne, j'arrive avec beaucoup de minutie a faire "glisser" la fenêtre fille derrière.
Il apparait donc que c'est un problème de focus.
Je vais investiguer dan cette voie.
Si vous avez des idées, je suis preneur.

EDIT 2 :

Pour ce qui est de l'utilisation modale, j'avais déjà essayé, et j'ai rententé, oubliant pourquoi j'avais abandonné cette piste.
Je viens de m'en rappeler. J'avais fait mon noob de base, qui recopie sans comprendre.
Je chope une exception

System.InvalidOperationException: Un formulaire qui n'est pas de niveau supérieur ne peut pas être affiché sous la forme d'une boîte de dialogue modale. Supprimez le formulaire des parents avant d'appeler showDialog.
à System.Windows.Forms.Form.ShowDialog
à System.Windows.Forms.Form.ShowDialog
....

Et du coup, piteux, je patauge...

EDIT 3:

Bon, là où je me suis fait avoir comme le noob mal dégrossi que je suis, c'est que j'ai un controltab dans ma mainform. Et du coup, c'est lui qui masque ma forme fille.
Si à l'appel de la formfille je mets un

ff.Visible = false

, effectivement, je vois bien ma nouvelle form.
D'où ma question :

Comment faire passer le controltab en arrière plan?

Celui ou celle qui m'aide, je lui donne un Kg de reconnaissance de première qualité!
A bientôt,
T@PµZ.

[ctxnop]

Bonjour !
Il y a des choses que j'ai un peu de mal a comprendre.
1) Concernant l'exception. C'est normal, un formulaire Mdi enfant ne peut pas être modal. Ca signifierai qu'on ne peux pas passer d'un formulaire enfant a un autre. Du coup, il n'y aurait absolument aucun intérêt a faire du Mdi. Pour qu le modal fonctionne, tu fais

Code csharp :

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

1
2
3
 
FormFille frm = new FormFille();
frm.ShowDialog(this); // this étant ton formulaire parent.

Ainsi, ta FormFille sera modal par rapport au formulaire de base, ce qui signifie que tant que tu ne quitte pas FormFille, alors ton formulaire de base est bloqué, ainsi que tous ses enfants.

2) J'ai rien compris concernant "le cheveux de pixel" correspondant a la FormFille.

3) Je comprend pas non plus ton histoire de controltab. Qu'est-ce qu'un controltab fouterai en plein milieu de la fenêtre, là où ironts les fenêtres Mdi enfant ??

[TaPuZ]

Coucou.
Tout d'abord merci de prendre du temps pour moi.

1) Pour le coup MDI Vs Modal, effectivement, c'est normal. J'ai compris maintenant. Rien à redire... Si ce n'est que le chemin est long jusqu'à l'aboutissement de ma formation d'apprenti futur padawan.

2) En fait, on peut oublier le "cheveu". C'est juste l'indice qui m'a permis de comprendre que ma FormFille s'ouvrait bien, mais qu'elle se positionnait systématiquement sous les contrôles de ma MainForm, qui eux (boutons, box, tab...) restent quoiqu'il en soit en premier plan. Et, j'ai beau avoir vérifié toutes les sortes d'options (dont TopMost), je n'arrive pas à ordonner à ma FormFille d'être au premier plan, le temps de l'ouverture de cette dernière. Voilà donc, après mes élucubrations investigatrices, à quoi se résume mon problème actuel.

3) C'est peut-être là aussi la marque d'un manque cruel de compétence de ma part. Dans ma MainForm, j'ai ma fenêtre occupée par 3 onglets, entre lesquels je navigue, selon la méthode que j'ai besoin d'appeler. Et de temps en temps, il me faut ouvrir une autre fenêtre, par dessus le tout, de type MessageBox, à la limite, mais dans laquelle je puisse mettre en forme avec des boutons des progressbar et des images. (d'où l'utilisation d'un formulaire à part entière).

Peut-être ai-je été un tantinet plus clair?

[ctxnop]

Donc absolument pas du tout besoin de Mdi. Ce sont des fenêtres classiques, peut-être même modale.
Ton formulaire parent ne doit pas du tout être un formulaire Mdi. C'est un formulaire classique, tout comme tes fenêtres "filles" (elle ne doivent plus non plus être qualifiées de fille puisque non Mdi).

Le problème qui va te rester est de déterminer si les fenêtres "filles" doivent ou non être modal et si elles doivent ou agir sur la fenêtre principale.

Il faut savoir que si tu fais un frm.Show(), le code continue de s'exécuter, la fenêtre s'ouvre, mais rien n'est bloqué, tu peux reprendre le focus sur la fenêtre principale et continuer a travailler dessus.
Par contre, si tu fais un frm.ShowDialog(), la fenêtre principale devient bloquée, tu ne peux plus travailler avec, tu ne peux travailler que dans le fenêtre fraichement ouverte. De plus, dans le code, la fonction ShowDialog ne fini sont exécution QUE quand la fenêtre "fille" est fermée.

[TaPuZ]

Disons que j'ai failli m'étrangler de rire...
Comment se noyer avec autant d'application dans un verre d'eau! Il fallait le faire!
Mais grâce à cela, j'ai pu comprendre de manière un peu plus fine toutes les différences entre MDI, Modal et "normal"
Tout est donc clair et transparent, mis à part un tout petit point turbide.
Dans quel cas aurais-je (en théorie donc, puisque cela ne me concerne plus pour le moment) intérêt à utiliser des MDI?

En tous les cas, merci beaucoup, et tant pis si mon appli ne fondera jamais la famille qu'elle espérait tant (mère, filles...).
Je m'en vais de ce pas appliquer tout cela.

Je mets tout de même le tag "résolu", car la suite n'appartient plus à ce post

Merci encore une fois à tous ceux qui ont eu la patience de me répondre.

A bientôt,
T@PµZ.

[ctxnop]

En fait, Mdi signifie Multiple Document Interface. Autrement dit, une interface a multiple document.
L'intérêt réside dans les application qui ouvrent de nombreuses fenêtres identiques en formes mais pas en contenue. Et par nombreuse j'entends un nombre indéterminé.

Par exemple, toi, tu n'as visiblement besoin d'ouvrir FrmFille qu'une seule et unique fois. Il n'y aura pas 2 instances de FrmFille à un instant T.

Par opposition, si je prend Visual Studio, il est typiquement Mdi (même s'il le cache un peu par l'utilisation d'onglets). Chaque onglet dans Visual Studio n'est pas un onglet comme dans le TabControl. Ce sont bien de fenêtres. Il peux ouvrir des dizaines de fenêtres contenant un code source. Toutes les fenêtres sont rigoureusement identique. En fait, c'est le même objet/classe qui se cache derrière. Seul le contenu change.
Chaque fenêtre est indépendante. Modifier le contenu d'une fenêtre n'influe pas sur les autres. En fait, la majorité du temps, les fenêtres fille n'ont aucune connaissance de leurs sœurs.
Tu remarquera qu'il est tout de même possible avoir des fenêtres très différentes visuellement les unes des autres. Toujours si je prend Visual Studio, tu as la fenêtre d'édition de code, mais également la fenêtre du Designer de formulaire, celle du diagramme de classe ou encore celle qui permet d'éditer les fichiers resources.
Mais toutes ces fenêtres regroupent des fonctions communes. Ouvrir, sauvegarder, fermer, commenter, ....
Et donc ces fonctions communes pourraient être rassemblées dans une fenêtre de plus haut niveau, c'est ce qu'on fait en placant les menus et barre d'outils dans la fenêtre parente.

Autre "avantage", le fait d'être Mdi signifie que la position des filles est relative a celle du parent. Autrement dit, si tu bouge la fenêtre parent, toutes les filles bougeront avec. Très pratique quand tu as deux écrans, si je devais bouger un à un tous mes onglets Visual Studio d'un écran l'autre, j'y passerai ma journée.

Dernier point (du moins dernier point important qui me viens a l'esprit). Quand tu fermes la fenêtre parente, ca fermera également toutes les fenêtres filles. Ce n'est pas le cas autrement (en pratique si, mais c'est a cause de la façon dont est lancée la fenêtre principale de l'application par le code auto-généré, fonction Main, c'est tout a fait modifiable).

Voila, c'est à peu près tout ce qu'il y a d'important a savoir. Il reste une multitude de petits points, mais rien de bien handicapant.

[TaPuZ]

Wow!
Je te remercie pour tes talents de pédagogue!
Bravo et merci.
Me voici blindé (à mon humble niveau) sur les fenêtres multiples.
Au passage, j'ai bel et bien obtenu ce que je cherchais au niveau de mon appli.
Bref tout va pour le mieux dans le meilleur de "mes" mondes...