label.texte ne fonctionne pas

Bonjour,

J'ai une fonction qui modifie le texte de mon label mais ça ne fonctionne pas.

Si je le fait en dehors de la fonction ça fonction, comme dans un OnClickButton mais pas dans ma fonction toute simple :

Code:

---

1 2 3 4 5

public void SetLabel(String Texte) { this.labelPhraseDuJour.Text = Texte; }

---

Cordialement,
Merci d'avance.

on peux voir l'appel de ta fonction ?

c'est laquelle des 2 lignes qui ne fonctionne pas ?
parce que dans le code que tu donne, si je ne me trompe pas, il y a 2 labels d'initialisés

OUI, montre nous ton appel de fonction, ça parait bizarre ton histoire...

Bonjour,

Merci de vos réponse.
Je vous montre l'appel de mes fonctions :

Dans une première Form (la principale avec le label) j'ai ces fonctions là :

Code:

---

1 2 3 4 5 6 7 8 9 10

public String GetLabel() { return labelPhraseDuJour.Text; }   public void SetLabel(String Texte) { this.labelPhraseDuJour.Text = Texte; }

---

Et dans une autre form, je les récupèrent :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

String Phrase = null;   private void FormOptions_Activated(object sender, EventArgs e) { this.Phrase = FrmPrincipale.GetLabel(); textBoxPhraseDuJour.Text = this.Phrase; }   private void buttonValider_Click(object sender, EventArgs e) { FrmPrincipale.SetLabel(textBoxPhraseDuJour.Text); FormOptions.ActiveForm.Dispose(); }

---

J'espère avoir été plus clair qu'au début sinon je le serai à nouveau. :D

Comment tu affiches ta fenêtre d'options ? et comment tu lui passes l'objet FrmPrincipale ?

Bonsoir,

Je l'affiche avec ShowDialog() et je récupére le texte du label comme ceci :

Code:

---

1 2 3 4

FormPrincipale FrmPrincipale = new FormPrincipale(); FrmFrmPrincipale.GetLabel(); FrmPrincipale.SetLabel(textBoxPhraseDuJour.Text);

---

Bing ! mauvaise réponse.

Tu utilises une nouvelle instance de FormPrincipale (donc une form différente), pas celle qui est affichée actuellement à l'écran.
Il faut modifier le constructeur de ta classe de fenêtre "options", et lui passer comme argument l'instance de la fenêtre actuelle (Me normalement) et utiliser cette référence pour effectuer tes opérations.

Donc en très gros

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

public class MainForm : Form { public void ShowOptions() { OptionsDialog dlg = new OptionsDialog(this); dlg.ShowDialog(); } }   public class OptionsDialog : Form { MainForm mainForm = null;   public OptionsDialog(MainForm parent) { mainForm = parent;   InitializeMachin();   txtBoxMachin.Text = mainForm.GetLabel(...); }   public void Valider() { mainForm.SetLabel(...); } }

---

Citation:

---

Envoyé par smyley

Bing ! mauvaise réponse.

---

Bing mauvaise réponse a toi aussi, c'Est une mauvaise pratique de passé une form a une autre form. Ce qui appartient a la MainForm doit rester a la mainform. OptionsDialog ne doit pas connaitre MainForm.

Mais bon.. il se fait tard :aie:

Citation:

---

Envoyé par shwin

Bing mauvaise réponse a toi aussi, c'Est une mauvaise pratique de passé une form a une autre form. Ce qui appartient a la MainForm doit rester a la mainform. OptionsDialog ne doit pas connaitre MainForm

---

tsss.
Le but premier est déjà d'arriver à faire quelque chose qui marche. En général le refactoring et les optimisations se font sur un programme qui marche, pas sur quelque chose qui n'affiche pas le résultat obtenu. Après une fois que ça marche si ça te/lui chante il suffit de faire "Extraire l'interface" pour créer une interface qui correspond ou alors créer une véritable classe qui stockes les informations de configuration, partagée entre la fenêtre principale et la fenêtre d'options.
Et puis sérieusement, ce n'est pas parce qu'on transmet une référence vers une form qui ça va mal fonctionner : d'ailleurs, ça fonctionne plus que bien. Comparé aux véritables mauvaises pratiques qui sont d'utiliser des chemins genre "MonFichier.txt" sans se soucier de savoir quel est le dossier courant ou de ne jamais vérifier si un objet n'est pas nul avant de l'utiliser ... et ça se sont des choses qui peuvent vraiment conduire à des crash ... je n'ai jamais vu personne se plaindre qu'il y ai une référence vers le fenêtre principale dans une "sous fenêtre" utilisée justement pour configurer la fenêtre principale.

Bonjour,

Tout d'abord merci de vos réponses !
J'ai fais comme tu m'as dis smyley et ça tourne bien, j'ai un peu cherché au début à comprendre comment tu faisais et j'ai compris :D

Mais apparemment niveau optimisation de code c'est pas recommandé comme le dis shwin ?

Encore merci.

Citation:

---

Envoyé par Couz02

Mais apparemment niveau optimisation de code c'est pas recommandé comme le dis shwin ?

---

C'est un point de vue. Personnellement j'ai pu constater que lorsque l'on essaye absolument de rentrer dans des patterns, structures complexes et sophistiquées pour pas grand chose (une fenêtre option ... :roll:) on fini par plus se prendre la tête sur la forme du programme plutôt que ce qu'il fait réellement et sur les petits projets c'est vraiment pas nécessaire de se prendre autant la tête à séparer les forms entre elles, surtout lorsque logiquement elles sont liées. Après ça c'est mon point de vue, sur les histoires de chemins relatifs par exemples je suis intransigeant :aie:

Mais bon, si ton application est de taille importante alors là le mieux à mon avis serait de faire une classe dédiée au stockage des options, partagée entre la form principale et la form d'options ... le truc c'est que maintenant que ça marche et que tu sais pourquoi (a priori) tu peux en faire ce que tu veux.

D'accord, ben je verrai plus tard alors pour ce genre d'exercice puis elle ne prend pas énormément de place en mémoire : 6 à 7 Mo.

D'ailleurs j'aurai bien voulu savoir ce que je pourrai optimiser dans un code niveau utilisation des ressources, la libérer un peu.

Basiquement, à moins d'avoir une énorme application à la usine à gaz, pas grand chose.

Il y a des petites pratiques qui sont de ne pas créer trop de forms, les libérer avec Dispose, pas trop de contrôles à la fois sur une form ... 'fin bref. Le GC derrière fait un travail assez correct mais il est très difficile de le contrôler, il agit comme il veux donc à moins d'utiliser des ressources natives (IntPtr et compagnie) sur lesquelles tu as un contrôle total, les optimisations véritables sont rares.

Oui je me doute bien que le GC fasse sont boulot mais bon si j'aurai pu l'aider un peu, ça aurait été mieux.

Sinon sur ce, encore merci pour les infos et quand tu dis : pas trop de forms, ça s'estime à combien à peu près ?

Citation:

---

Envoyé par Couz02

Oui je me doute bien que le GC fasse sont boulot mais bon si j'aurai pu l'aider un peu, ça aurait été mieux.

---

Bah si tu cherches GC ou Garbage Collector sur le forum ou sur google, tu verra que ce n'est pas une tâche évidente. Il y a toujours les IDisposable et compagnie mais bon ...

Citation:

---

Envoyé par Couz02

pas trop de forms, ça s'estime à combien à peu près ?

---

Bah pas trop de forms en même temps ... dès que ça reste à échelle humaine.
Quand je vois passer des messages avec quelqu'un qui veux afficher une form avec 200 TextBox et boutons associés je ne peux que me poser de très sérieuses question ... le truc que j'ai remarqué c'est surtout de libérer les form après usage avec ZeForm.Dispose();

Citation:

---

Envoyé par smyley

le truc que j'ai remarqué c'est surtout de libérer les form après usage avec ZeForm.Dispose();

---

Oui oui, je l'utilise aussi à chaque fois que je close() la form.

Bon ben merci pour tout !