Oder so ähnlich. Ich stand gestern ganz schön im Wald, Grund: das Event-Handling - bzw. der Unterschied zw. ASP.NET und "echten Forms" in diesem Gebiet.
Von ASP.NET bin ich es gewohnt, dass ein Event erst wirklich dann gefeuert wird, wenn der User entsprechend interagiert - klar, HTTP ist zustandslos, ASP.NET nach Auslieferung des HTML-Dokumentes tot - da geht es erst weiter bzw. wieder los, wenn ein Request an den Server geschickt wird.
Im konkreten Beispiel ging es bei mir um eine DropDownList (bzw. ComboBox), für die ein OnSelectedIndexChanged-Event definiert war. Bei ASP.NET muss der Benutzer tatsächlich etwas neues auswählen, damit die Event-Methode aufgerufen wird, nun ging ich erstmal davon aus, dass das bei Winforms auch so ist.
Ich setzte also meine ComboBox in die Form, klickte einmal doppelt drauf, platzierte eine Reihe "teuren" Code darin. Beim nächsten Start der Form wunderte ich mich schon, warum alles so lange dauert ...
Was war passiert?
Ganz einfach: ich hatte beim Initialisieren der Box selbstverständlich Werte eingefüllt. Und bei jedem neuen via Add() hinzugefügten Item wurde das Event gefeuert ... -> Klar - es änderte sich ja der Index! Und da wir uns hier nicht mehr im zustandslosen Raum befinden, sondern die Form "live" mitbekommt, was passiert, wurde nun das Event immer gleich gefeuert.
Die Lösung dafür: das Event wird erst nach dem Initialisieren von Hand registriert. Normalerweise erledigt das gleich Visual Studio beim Doppelklick auf die ComboBox, deshalb muss der Eintrag aus der Form.Designer.cs herausgenommen, und einfach nach die Initialisierung gesetzt werden:
this.comboBox1.SelectedIndexChanged += new
System.EventHandler(this.comboBox1_SelectedIndexChanged);