Mal ne Frage zu Control.Invoke(Delegate)

Ist ist grundsätzlich unmöglich, die ObjectDisposedException zu verhindern, falls der User im event-handling Thread die Form schließt? Mir drängt sich gerade dieser Verdacht auf aber es würde mich wenig erquicken, um jedes Invoke() einen try-catch-Block zu bauen.

also wo fange ich an wenn Du irgendwas aufrufst wo nur ungefähr gehört hast was es macht, such den KRAM inder MSDN...

Wichtig dabei steht dort dann das es ne Exception werfen kann lies was es wirft und aus welchen Gruenden!

Wirft es ne Exception baue ne Try/Catch-Klausel-WieAuchImmer Drum!

Im übrigen mich kostet nen Try/Catch zu machen nur einen Mausklick
Wenn Du auch mit VS 2003 oder 2005 atbeitest kann du das auch so einfach haben wie ich. Dann lies mal folgenden Link den fuer kurz Standardkonstrukte verwende ich dies

http://www.microsoft.com/germany/msdn/library/visualtools/ToolboxInVSNETFuerCodeschnipselNutzen.mspx

also ist nur meine persöhnliche Meinung

man koennte sich ja gleich so nen Codeschnipsel bauen und eben in diesen Ablagering packen.

hmm

@Optimizer

Entschuldige wenn ich vielleicht mit dem "Grundsätzlichen ...."

zu sehr schulmeisterlich ruebergekommen bin

Hast ja schliesslich mehr Postings als ich also ich struen jetzt schonmal Asche auf mein Haupt

Mit freundlichem Gruss sclearscreen

Das Problem ist wie immer nicht die Schreibarbeit, sondern die Wartungsarbeit. Einen try-catch Block macht man nicht einfach drum herum, sondern man dokumentiert, warum der da steht und unvermeidbar ist. Im Moment steht da ein Zitat aus der MSDN.

Die Frage ist, ob der wirklich unvermeidbar ist. Ich habe nicht nur ungefähr gehört, was Invoke() macht, sondern ich weiß es ganz genau. Es reiht eine Windows Message in die Message Queue des Threads, dem dieses Control gehört, ein. Wenn vorher ein WM_CLOSE eingereiht wird, ist nicht das Problem, dass das, was Invoke() aufruft Ärger macht, da könnte ich ja auf IsDisposed testen. Das Problem ist, dass der Aufruf von Invoke() selber fehlschlägt und ich frage mich, ob es eine Möglichkeit gibt, das vorher abzufragen.

Optimizer schrieb:

Ist ist grundsätzlich unmöglich, die ObjectDisposedException zu verhindern, falls der User im event-handling Thread die Form schließt? Mir drängt sich gerade dieser Verdacht auf aber es würde mich wenig erquicken, um jedes Invoke() einen try-catch-Block zu bauen.

Ich habe jetzt mal inner MSDN geguckt die schreibt dazu:

Hinweise
Wenn das Handle des Steuerelements noch nicht vorhanden ist, durchsucht diese Methode die Kette der übergeordneten Elemente bis zu einem Steuerelement oder Formular, für das ein Fensterhandle vorhanden ist. Wenn kein geeignetes Handle gefunden werden kann, löst die Invoke-Methode eine Ausnahme aus. Während des Aufrufs ausgelöste Ausnahmen werden an den Aufrufer weitergegeben.

also Du brauchst Try/Catch definitiv wenn ich das so lese.

Optimizer schrieb:

Das Problem ist wie immer nicht die Schreibarbeit, sondern die Wartungsarbeit. Einen try-catch Block macht man nicht einfach drum herum, sondern man dokumentiert, warum der da steht und unvermeidbar ist. Im Moment steht da ein Zitat aus der MSDN.

Die Frage ist, ob der wirklich unvermeidbar ist. Ich habe nicht nur ungefähr gehört, was Invoke() macht, sondern ich weiß es ganz genau. Es reiht eine Windows Message in die Message Queue des Threads, dem dieses Control gehört, ein. Wenn vorher ein WM_CLOSE eingereiht wird, ist nicht das Problem, dass das, was Invoke() aufruft Ärger macht, da könnte ich ja auf IsDisposed testen. Das Problem ist, dass der Aufruf von Invoke() selber fehlschlägt und ich frage mich, ob es eine Möglichkeit gibt, das vorher abzufragen.

Upps dann ergründet sich Dein Wissen bestimmt genau auf das was ich jetzt eben auch gefunden habe

und wenn Du ein DummyControl reinbaust

was im Prinzip leer ist was sozusagen immer am Ende dieser Kette steht
wichtig wäre nathuerlich es muss sichergestellt werden das es wirklich am Ende dieser Kette sitzt.

Irgendsowas ich weiss jetzt nicht ob ich meine Gedanken irgendwie formulieren konnte und ob das überhaupt geht.

wenn ich das richtig verstehe ist dies

protected override void OnHandleDestroyed(EventArgs e)
      {
         // If the handle is being destroyed and you are not
         // recreating it, then abort the search.
         if (!RecreatingHandle)
         {
            StopSearch();
         }
         base.OnHandleDestroyed(e);
      }

eine Methode des Steuerelemenst oder wie auch immer die auch nützlich sein könnte
ein Bauchgefühl sagt mir das das auch irgendwie zu diesem Thema passt

k.A. hmm

nee der vorletzte Post von mir ist Russ!!!

Mein potenzielles Problem ist nicht, dass das Handle noch nicht erstellt worden ist ist, sondern dass das Steuerelement disposed wird, der invokende Thread das aber nicht merkt, wenn er IsDisposed frägt - eine klassische race condition einfach.

Der entscheidende Unterschied zu typischen Fällen ist aber, dass keine Synchronisierung möglich ist, da man den event-handling Thread blocken müsste, dadurch würde aber auch Invoke() nicht mehr zurückkehren, da Invoke() den aufrufenden Thread so lange blockiert, bis der event Thread den Delegate ausgeführt hat.

Daher meine Frage, kann man den Vorgang irgendwie doch synchronisieren und meine Vermutung, wahrscheinlich hilft nur die ObjectDisposedException fangen.

EDIT: Gibt es ein Invoke(), das den aufrufenden Thread nicht blockiert? Dann könnte ich nämlich vorher synchronisieren, das wäre eine Lösung ganz nach meinem Geschmack. In meinem Fall muss ich nach Invoke() nichts mehr machen, also ist es egal, ob nach der Rückkehr der Delegate schon ausgeführt ist. Aber kein Bock, das selber zu coden.
EDIT2: Ne, würde mir gar nichts bringen. Ich müsste sicherstellen, dass invoke vor close in die Queue kommt.