[C# Windows Forms] Window_Load arbeitet mein Code nicht ab

[Mars007]

Ich arbeite gerade an meinem ersten C# Programm. Dabei werden im
private void Window_Load(object sender, EventArgs e) { ... }
zwei Textdateien geöffnet, meine Kinect initialisiert und deren Videostream samt Skeletondata in eine PictureBox transferiert, und die Sprachsteuerung gestartet.

Gestaltet ich den Code in der Form
{init kinect_video; init sprachsteuerung;}
dann habe ich das Video auf dem Bildschirm, aber keine Sprachsteuerung.

Gestalte ich den Code so:
{init sprachsteuerung; init kinect_video;}
dann funktioniert die Sprachsteuerung, aber es fehlt das Video.

Im Debug-Modus sieht man sehr schön, dass je mehr Code ich in Windows_Load{} schreibe, desto weniger wird abgearbeitet. Die naheliegende Idee, den Code in eine Unterfunktion auszulagern hilft leider auch nicht.

Was mache ich falsch?

[Mars007]

PC neu starten hat geholfen.
(normalerweise nutze ich immer den Ruhezustand)

Da studiere ich extra IT, weil ich nach 10 Jahren Elektronik die Nase voll von sporadischen Problemen,
Timing- und Temperaturfehlern habe, und jetzt ist es beim Programmieren genau der gleiche Käse. :mad:

[PatkIllA]

Warum hast du dann eigentlich mit Forms angefangen und nicht WPF benutzt?

Arbeitest du evtl mit Threads? Die machen bei unsauberer Benutzung (nicht nur) in der GUI-Programmierung so manch komische Effekte. Insbesondere da man bei Forms die Crossthreads-Checks auch abstellen kann bzw im Release sind die gar nicht erst an.

[Mars007]

Ich brauche relativ viel Input vom User und dementsprechend mehrere Schaltflächen usw.
Da ich vom programmieren eher wenig Ahnung habe, habe ich mich spontan für Windows Forms entschieden.
WPF war, zumindest auf den ersten Blick, etwas unübersichtlich.

Von Threads möchte ich vorerst die Finger lassen. Ich ahne schon dass sich die Probleme dann quadrieren würden.

[PatkIllA]

Man kann auch in WPF fast genauso wie in Forms programmieren.
Wenn man allerdings erstmal die Eleganz von XAML und Datenbindung/Convertern/Templates drin hat will man nicht mehr zurück.

[Yavion]

PC neu starten hat geholfen.
(normalerweise nutze ich immer den Ruhezustand)

Da studiere ich extra IT, weil ich nach 10 Jahren Elektronik die Nase voll von sporadischen Problemen,
Timing- und Temperaturfehlern habe, und jetzt ist es beim Programmieren genau der gleiche Käse. :mad:

Es klingt nach einer Nebenläufigkeit. Wenn nicht von Dir beabsichtigt, müsstest Du den Fehler im Debugger eingrenzen können. Wenn du nichts findest, dann auch den autogenerierten Code des Designers mal Abschnittweise debuggen.

Ich hatte gerade mit Forms ein ganz ähnliches Problem. Programm A läuft auf allen möglichen Rechnern und Systemen bis auf dem System, wo es laufen soll. :rolleyes:
Debugger hat nichts gefunden, da ja auf meinem System alles glatt durchlief. NET-Deinstalliert, Ziel-Runtime gewechselt, immer die selbe Leier.
Dann eine Express Ide auf dem Problemsystem installiert, debugt und prompt: Nullpointer-Exception und zwar bei der Initialisierung der Form, weil eine BindingList zu einem bestimmten Zeitpunkt noch nicht da war.
Code umgestellt - läuft.

Was ich damit sagen will: Auch ohne Nebenläufigkeiten ist die Ausführung eines .NET-Programms nicht immer deterministisch. :wink:

[Gnafoo]

Es gibt da einen kuriosen Bug, bei dem Exceptions in Form_Load verschluckt werden. Da bin ich auch schon drüber gestolpert und eventuell ist dir ja dasselbe passiert? Kurz gesagt wird Form_Load an der Stelle verlassen, an welcher die Exception auftritt und das Programm läuft weiter, als wäre nichts gewesen. Das passiert auch, wenn man im Debugger durch den Code steppt. Die Hälfte von Form_Load läuft dann ggf. nicht.

Hier die beste Erklärung, die ich eben mit Google finden konnte:
http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/

Das kann ich auch hier auf meinem 64-Bit Win-7 rekonstruieren, wenn ich x86 als Zielplattform wähle (Visual Studio 2008 und 2010).

[PatkIllA]

Wenn man Exceptions vermutet kann man immer Debugger auch bei allen oder bestimmten Exceptiontypen anhalten. Oft deutlich einfacher als durchzusteppen.

[Gnafoo]

Naja normalerweise meldet sich der Debugger ja bei einer unbehandelten Exception von alleine. Bei diesem Bug ist das allerdings nicht der Fall.
Die Exception explizit beim ersten Auftreten abzufangen (Debug → Exceptions…) hilft in dieser Situation tatsächlich, ist aber imho auch nicht gerade naheliegend.

[PatkIllA]

Man sieht ja leider immer wieder das irgendwelche Spezialisten, die um alles ein try {} catch {} machen, weil sie denken, dass man so Fehler behebt.

In einem größeren System werden Exception ja auch durchmal etliche Ebenen immer wieder in neue Exceptions verpackt und da ist man bei halten an allen Exceptions auch schneller am Ziel.

[Yavion]

Hier die beste Erklärung, die ich eben mit Google finden konnte:
http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/

Das kann ich auch hier auf meinem 64-Bit Win-7 rekonstruieren, wenn ich x86 als Zielplattform wähle (Visual Studio 2008 und 2010).

Der war es. Besten Dank.
Das erklärt auch, warum das Programm auf dem Problemsystem einfach beendet wurde. Normalerweise bekommt man ja bei nicht gefangenen Exceptions eine entsprechende Meldung.

[Gnafoo]

@PatkIllA: Jop mag sein. In so einer einfachen Situation würde ich aber auch zuerst mit dem Debugger durch die Load durchsteppen und wäre doch sehr verwundert, wenn ich auf einmal aus der Load rausgeschmissen würde, ohne dass der Debugger eine Exception meldet.

Hängt aber eventuell auch damit zusammen, dass ich bisher überwiegend mit meinem eigenen Code arbeiten musste und so etwas wie try { … } catch { } dort nicht vorkommt ^^.

[PatkIllA]

@PatkIllA: Jop mag sein. In so einer einfachen Situation würde ich aber auch zuerst mit dem Debugger durch die Load durchsteppen und wäre doch sehr verwundert, wenn ich auf einmal aus der Load rausgeschmissen würde, ohne dass der Debugger eine Exception meldet.

Hängt aber eventuell auch damit zusammen, dass ich bisher überwiegend mit meinem eigenen Code arbeiten musste und so etwas wie try { … } catch { } dort nicht vorkommt ^^.
Wenn einige hunderttausend Zeilen Code von 20 Leuten zusammen zu halten zu versucht solpert man über so einiges. ;)

Das mit der Exception bei OnLoad kannte ich auch noch nicht.

[myMind]

Hier die beste Erklärung, die ich eben mit Google finden konnte:
http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/

Danke für den Link. Ist ja sehr interessant. Man mag sowas ja immer gar nicht glauben.

[PatkIllA]

Danke für den Link. Ist ja sehr interessant. Man mag sowas ja immer gar nicht glauben.
Yup. Ein ordentliches Abstürzen wäre IMO definitiv besser gewesen.

[DocEW]

Ahh, diesen fiesen Bug hatte ich auch schonmal (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=458291)!

[Gnafoo]

Ach sieh an. Von daher kannte ich das also XD.

Hatte die Situation aber auch schon selber, wenn mich meine Erinnerung nicht trügt.
Auf jeden Fall ein blöder Bug. Ein Absturz wäre definitiv besser.

[Mars007]

Wow. Hier ist geballte Kompetenz vorhanden.
Vielen Dank für die tollen Infos. :up:


Jetzt wird mein Code in Form_Load abgearbeitet, aber dann legt sich mein
PC auf die faule Haut bzw. meine Spracherkennung nimmt nix entgegen.
Ich sehe noch, wie die Spracherkennung geladen wird, aber wenn ich rede
passiert nix.

Der selbe Code, in eine Konsolenanwendung geschrieben, und ich kann mein
PC endlos zutexten. Der erkennt alles.

Aber darum kümmere ich mich nächste Woche.

[PatkIllA]

Was machst du denn da alles im Load? Ich hab da noch nie was längeres reinschreiben müssen?
Das ist nicht zufällig ein synchroner Funktionsaufruf?

[Mars007]

Zumindest von meiner Seite ist da nix synchron. Ich frage mich aber was die KinectSDK alles im Hintergrund treibt.

Ich lasse vom Load eine Textdatei mit den Settings einlesen, die Kinect mitsamt Video- und Skeleton-stream starten
und zu guter letzt die Spracherkennung. Der Code ist keine 50 Zeilen lang.
Im wesentlichen werden nur einige Eventhandler gestartet.

[PatkIllA]

Mit synchron meine ich, dass das Programm dann an der Stelle stehen bleibt. Zum Beispiel gibt es Funktionen, die so gedacht sind, dass die in einem extra Thread laufen sollten. Ist aber jetzt nur eine Vermutung, da ich das SDK nicht kenne. Wäre aber beim nebenläufigen Verarbeiten von mehreren Datenströmen nicht unwahrscheinlich.
Wenn du das im Hauptthread machst geht bei dem Fenster nichts mehr.

Was meinst du mit EventHandler "starten"?

[Mars007]

Sorry für meine ungünstige Wortwahl. Wie ich schon schrieb: Das ist sozusagen mein erstes,
richtiges Programm, das ich zusammen schuster.

Mit "starten" meine ich das da:
nui.SkeletonFrameReady += new EventHandler<SkeletonFrameReadyEventArgs>(Nui_SkeletonFrameReady);
Nennt sich vermutlich anmelden oder irgendwie so.

Über das Synchronthema muss ich echt nochmal nachdenken. Möglicherweise hast du die richtige Fährte gefunden.