Hier mal ein kurzer Braindump von mir zu Thema Designer und dessen Probleme (inkl. ein paar Lösungsansätze):
Der Designer erzeugt ein reales Objekt von der Klasse um dieses dann anzeigen zu können. Besonders vor VS2005 hat das immer wieder zu Problemen geführt, da hier der Designer generierte Code nicht in einer separaten Designer Code Datei gehalten wurde, sondern in der selben Code-Datei gespeichert wurde, wie das was man selbst programmierte. Das Problem an der Sache war, dass zwar alle Events abgeschalten waren, d.h. die selbst erstellten Eventhandler wurden nicht ausgeführt, aber die entsprechenden EventRaise-Methoden, z.B. OnClick(), OnFormClosing(), OnLoad() waren nachwievor aktiv. Da half nur in den überschriebenen Methoden dann am Anfang zu prüfen ob this.DesignMode = True war. In diesem Fall hat man die Basismethode aufgerufen und mit Return verhindert, das eigener Code im Designer nicht aktiv wurde.
Ab VS2005 ist das Ganze etwas besser geworden, da hier der eigene Code auch physisch vom Designer Code getrennt wurde. Das Grundproblem blieb jedoch bestehen, wenn man eigene UserControls oder Komponenten geschrieben hatte, die dann auf der Form verwendet wurden. Der eigene Code wird u.U. im Designer aktiv, da der Designer wie gesagt eine reale Objektinstanz erzeugt und entsprechend auch dann den eigenen Initialisierungscode, z.B. Konstruktor, oder auch die EventRaise Methoden ausführt.
Soviel zu Theorie, nun etwas Praxis.
Man kann seinen eigenen Code auch im Visual Studio debuggen um mal zu schauen welche Methode nun durch den Designer ausgeführt wurde und zu dem Fehler führt. Das funktioniert jedoch nicht mit den Express Varianten von VS sondern erst ab Standard, evtl. ist da VS2010 Express besser, das kann ich aber mangels Installation nicht testen und wäre dankbar, wenn mir einer mal paar Infos darüber rausgibt. Also folgendermaßen debuggt man den Code, wenn er im Designer geladen wird:
Bei den Projekteinstellungen gibt man unter dem Punkt "Debuggen" entweder das Programm selbst oder eine beliebige andere Anwendung zum Debuggen an. Hier muss man den exakten Pfad zur devenv.exe (inkl. devenv.exe) angeben. Ganz in der Nähe von diesem Feld gibt es ein weiteres Feld wo man die Befehlszeilenparameter für den Debug-Start angibt. In dieses Feld trägt man nun den exakten Pfad (inkl. Name) der Solution-Datei ein. Danach erstmal Änderungen speichern.
Externes Programm starten: "C:\Progamme\VS_XYZ\devenv.exe"
Befehlszeilenargumenten: "X:\MyCodes\MySolution\MySolution.sln"
Wenn ihr nun das Debuggen startet, lädt eine zweite Visual Studio Instanz und öffnet das Projekt zum 2. Mal. Der Debugger von VS verbindet sich dabei automatisch mit der 2. VS Instanz und versetzt diese in den Debugmodus. Ihr könnt nun in euren eigenen Quellcodes innerhalb der 1. Instanz eure Breakpoints über all da setzen, wo ihr vermutet, wo das Problem stecken könnte, z.b. im Konstruktor der extErrorProvider Klasse. Danach ladet ihr in der 2. Instanz den Designer der Form. Wenn ihr die Breakpoints richtig gesetzt habt, dann unterbricht das erste Visual Studio die Ausführung und ihr könnt wie gewohnt mit dem Debugger durch die einzelnen Anweisungen steppen. So sollte auch so manch ungelöstes Problem im Designer vor euren Augen aufblitzen, es sei denn ihr landet unmittelbar dank Exception an der entsprechenden Zeile.
Hier noch ein Code-Schnipsel wie ich typischerweise den Designer an der Ausführung meines eigenen Codes hindere:
Code:
protected override void OnLoad(System.EventArgs e)
{
if(this.DesignMode)
{
base.OnLoad(e);
return;
}
// my own code follows now
this.Text = "Hello world!";
}
Desweiteren habe ich hin und wieder Designer Probleme dadurch lösen können in dem ich die von VS dynamisch generierten Binärdateien *.user und *.suo vor dem Öffnen des Projektes im Explorer gelöscht habe.
Manchmal ist auch eine krumme *.resx Datei des Formulars dran Schuld gewesen, dass er das Formular nicht laden konnte. Jedoch kann ich da nicht generell empfehlen diese zu löschen, da hier evtl. auch Übersetzungen für mehrsprachige Assemblies sowie wichtige weitere Resourcen ala Bilder, Icons etc. enthalten sind und diese dann dabei verloren gehen. Sollte man aber darauf verzichten können, weil man keine mehrsprachige Assembly erzeugt und auch sonst nichts spezielles in die resx Datei reinschmeißt, dann reicht das Löschen aus. Der Designer kann das Formular dennoch laden, da er nicht wirklich diese Datei benötigt und sie beim nächsten Serialisieren, sprich wenn man eine Änderung im Formular vornimmt, dann neu erzeugt.
Das wären so meine Erfahrungen und möglichen Lösungen bei Designerproblemen im Visual Studio. Ich hoffe das es euch vielleicht einmal weiterhelfen kann.
Viele Grüße
Rossibaer
