[C#] Effets inattendus de static

J'ai attribué a deux types de composants (PictureBox et MenuItem les modificateurs public et static. Le modificateur public a été défini dans la fenêtre de propriétés des composants.Le modificateur public l'a été manuellement dans les ligne de code des déclarations.
Cela a eu pour résultat, au bout d'un "certaint temps" de suppimer purement et simplement ces composants de la form... Le code correspondant reste en place. Je redessine les composants avec le même nom (en mettant en commentaire les anciennes ligne de déclaration niveau classe), ces lignes sont alors recréées et tout repart.. jusqu'à nouvelle disparition. Que ce passet-t-il et comment palier le problème?
Merci.

Euh, alors d'abord j'ai pas tout compris...
Ensuite, j'ai encore moins compris le coup des modificateurs static...Quelle peut bien être leur utilité alors que tu travailles sur des instances ???

Citation:

---

Envoyé par jacma

Que ce passet-t-il et comment palier le problème?

---

Ben c'est un peu normal. Les composants que tu vois dans le designer sont des composants appartenant à une instance de ta classe. Si tu les mets en static, ils n'appartiennent plus à une instance, donc ils dégagent. Réflexe habituel du designer. "un doute ? allez, on vire". Ce que dans un sens je préfère à la méthode "un doute ? allez, on essaye de deviner les intentions du dév et on change tout selon cette supposition".
Mais ça reste moins bien que "un doute ? et si on demandait au dév avant de faire des conneries ?"

Mais la grande question c'est celle de Keihilin : à quoi ça te sert de mettre du static ?

Le modificateur static pour la PictureBox a été introduit afin de résoudre le problème de l'image dans une MDI (voir http://www.developpez.net/forums/viewtopic.php?t=266769). Dans le dernier topic de cette enfilade, je posais la question

Citation:

---

est-ce un bon emploi pour static?

---

et ne voyant rien venir, j'ai vaillament continué dans ce sens... jusqu'à l'apparition du phénomène. :(
Et comme un problème similaire (accès à un composnt de la MDI mère de puis une MDI fille), j'ai fait de même pour les menus :) , avec le même résultat bien sûr.
Alors, est-ce à dire que je reviens à la case départ avec mon image dans ma MDI?

moi je fais ça en utilisant BackGroundImage et pour pas que l'image ne s'affiche avec un effet mosaique elle a la taille de l'écran max.
Peut-être pas élégant, mais comme tu peux sélectionner un jpg, ça n'encombre pas trop la mémoire...

Apparament le fait de mettre static pour la pictureBox ne gene pas l'exécution du programme mais seulement celle du concepteur alors tu fait ton dev sans l'image et au moment du release tu l'ajoutes. Ensuite tu fait des tests poussés pour savoir si ça fonctionne sans pb ... :wink: :bug:

Merci à tous. Je pense avoir trouvé une solution, mais je vais bien me garder de crier victoire trop tot ce coup là :wink:
J'ai repris une indication de dev01 datant d'avant hier je crois qui m'orientait vers un truc du genre

Code:

---

frmAccueil myAccueil1 = (frmAccueil)this.Owner;

---

Ca plantait, et on a abandonné (peut-être trop tot). Je suis donc reparti sur cette voie avec le principe que Owner indique le propriétaire (conteneur) d'un formulaire, en l'occurence la feuille MDI mère. Or, qu'est une feuille MDI mère sinon un conteneur :?: J'ai donc écris le code suivant:

Code:

---

1 2 3 4 5

{private void frmAuteurs_Closing(object sender, frmAccueil myAccueil1 = (frmAccueil)this.MdiParent; myAccueil1.mnuAuteurs.Enabled = true; myAccueil1.pbTitre.Visible = true; }

---

et cela semble fonctionner tout à fait correctement.
Voyez vous une faille?

Citation:

---

Envoyé par jacma

Voyez vous une faille?

---

Ben que toutes tes fenêtres enfants doivent aller taper dans la fenêtre principale pour rendre visible un contrôle qu'elles n'ont pas à connaitre, et je suis pas sûr du comportement quand ces fenêtres ne recouvrent que partiellement ton image de fond.

Enfin c'est pas très OO quoi :)

Citation:

---

Envoyé par Maniak

Ben que toutes tes fenêtres enfants doivent aller taper dans la fenêtre principale pour rendre visible un contrôle qu'elles n'ont pas à connaitre, et je suis pas sûr du comportement quand ces fenêtres ne recouvrent que partiellement ton image de fond.
Enfin c'est pas très OO quoi :)

---

Toutes les fenêtres filles sont plein écran. Et puis, comme les fenêtres filles sont dépendantes de la fenêtre mère et n'existent que par elle, il me semble qu'elle peuvent "connaître" la fenêtre mère à laquelle elles sont intimement liées. Mais c'est vrai que si le menu de la feuille mère est modifié, cela peut entrainer une modification dans les feuilles filles. C'est probablement la raison qui entraîne ton doute quant à l'aspect POO?
Si c'est celà, il y a peut-être possibilité de déporter vers la feuille mère le contrôle de l'image et des menus. Je vais voir dans ce sens. Je suis preneur de toute suggestion.
Merci.

Citation:

---

Envoyé par jacma

Si c'est celà, il y a peut-être possibilité de déporter vers la feuille mère le contrôle de l'image et des menus.

---

L'évènement ChildActivate fonctionne dans les deux sens. J'ai été chercher bien loin ce qui était sous mes yeux :oops: :?

Citation:

---

Envoyé par jacma

Mais c'est vrai que si le menu de la feuille mère est modifié, cela peut entrainer une modification dans les feuilles filles. C'est probablement la raison qui entraîne ton doute quant à l'aspect POO?

---

Pas spécifiquement, mais c'est l'idée. À partir du moment où tu fais un couplage aussi serré entre un objet 'créateur' et tous ses objets 'créés', tu t'exposes à pas mal d'effets secondaires par la suite, quand il y a des changements du côté créateur. C'est pour ça qu'il faut essayer de limiter au maximum les couplages.

Que les fenêtres enfants connaissent la fenêtre parent pour pouvoir toucher à son menu ou a un de ses contrôles, ça ne semble pas normal non :)

Citation:

---

Envoyé par jacma

Si c'est celà, il y a peut-être possibilité de déporter vers la feuille mère le contrôle de l'image et des menus. Je vais voir dans ce sens. Je suis preneur de toute suggestion.

---

C'est le rôle des évènements donc :)

Citation:

---

Envoyé par jacma

L'évènement ChildActivate fonctionne dans les deux sens. J'ai été chercher bien loin ce qui était sous mes yeux :oops: :?

---

Ah ben voilà :)