Visual C# GUI Designer - Méthode recommandée pour supprimer le code de gestionnaire d'événement généré

Question

Je suis nouveau au concepteur de Visual C#, il s'agit donc de questions générales et assez simples sur la façon de travailler avec le concepteur.

Lorsque nous, par exemple, ajouter une étiquette à une forme, puis double-cliquez dessus dans le concepteur Visual C# (j'utilise Microsoft Visual C# 2008 Express Edition), les choses suivantes se produisent:

1. le concepteur génère du code dans les Form1.Designer.cs (en supposant des noms par défaut pour la simplicité) pour ajouter l'étiquette,

2. puis avec le double-cliquez dessus ajoutera le gestionnaire d'événements label1_Click à l'étiquette dans Form1.Designer. cs, en utilisant le code suivant

   this.label1.Click + = new System.EventHandler (this.label1_Click);

et il ajoute la méthode de gestionnaire d'événements à Form1.cs

private void label1_Click(object sender, EventArgs e) 
{ 

} 

Si je retire maintenant l'étiquette que le code dans Form1.Designer.cs sera supprimé mais la méthode label1_Click sera rester dans Form1.cs même s'il n'est pas utilisé par autre chose. Mais si j'utilise reset dans Propriétés-> Events pour l'événement Click dans le concepteur même la méthode label1_Click dans Form1.cs sera supprimée. 1.) N'est-ce pas un comportement peu incohérent?

2.) Quelle est la méthode recommandée pour supprimer un tel code de gestionnaire d'événement généré?

3.) Quelle est la meilleure «approche mentale»/meilleure pratique pour utiliser le concepteur? Je l'aborderais par séparation mentale de la façon dont Form1.cs est à 100% de ma responsabilité et que d'autre part je ne touche pas du tout le code de Form1.Designer.cs. Cela a-t-il un sens ou non? Depuis parfois le concepteur supprime sth. de Form1.cs je ne suis pas sûr à ce sujet.

Answer 1

1) Oui, c'est incohérent. Un peu. 2) J'ai utilisé une approche BEAUCOUP PLUS SIMPLE: effacez simplement tout votre code de poignée et essayez de compiler => le compilateur vous montrera où effacer une assignation d'événement. Malgré un look effrayant, c'est vraiment sûr. 3) Voici mes meilleures pratiques que je recommande et que j'applique dans mon département logiciel: 3a) Passer à WPF (demander les meilleures pratiques WPF séparément, il y a beaucoup d'autres problèmes); 3b) NE JAMAIS permettre à Visual Studio de générer automatiquement un code d'événement (WPF ou Windows.Forms); en cas d'accident, utiliser (2) dès que possible; 3b) Pour une utilisation d'affectation des événements anonymes lambda:

ByButton.Click += (source, evArg) => { SomeHandler(...); }; 

pour v.2.0:

ByButton.Click += delegate(object source, EventArgs evArgs) { SomeHandler(...); }; 

Il y a de nombreux avantages: vos gestionnaires ne sont pas liés à l'utilisation de profil de méthode spécifique; vous pouvez mettre du code entier dans un gestionnaire anonyme s'il est assez court, sous forme lambda vous n'aurez peut-être jamais besoin de connaître le type des arguments d'événement ...

Answer 2

Il existe probablement un élément de sécurité intégré à Visual Studio.

Par exemple:

• bouton Ajouter un A et un événement de clic.
• Référence du bouton A événement de clic d'un autre bouton B.
• bouton Supprimer A
  • si le code devait aller puis sur le bouton B romprait
  • si le code reste alors le bouton B continue de travailler.

Je commente en général sur tout code (gestionnaires d'événements) qui se brisent dans le fichier designer.cs.