Helfen Sie mir diese Aufrufliste zu analysieren was ruft meine Methode, um zu sehen

Question

Ok, also habe ich eine sehr einfache Form mit so gut wie keine Logik darin, die durch von einem Moderator gesteuert wird. Es gibt ein Verfahren auf sie public void Reset (), die das Formular in den Ausgangszustand zurücksetzt. Dies sollte nur von den Vortragenden und in ganz bestimmten Fällen (wie eine Aktivität Timeout) aufgerufen werden. Ich laufe in ein Problem, obwohl, wo in ein paar Grenzfällen (Wenn ich meine Anwendung zu simulieren verliert Datenbank-Konnektivität zum Beispiel), um den Reset () -Methode aufgerufen wird, wenn es nicht sein sollte, und ich kann nicht herausfinden, was .

Also habe ich eine Tracepoint am Reset () Methode aufgebaut und haben es die Aufrufhierarchie drucken. Seltsam genug, dass noch mehr Fragen aufgeworfen. Kann mir jemand helfen, herauszufinden, wo der Anruf () Zurücksetzen herkommt? Meine Aufrufliste ist unten.

Eine Sache, die ich erklären soll, ist DriverInterface2.UI.WinForms.NonInheritingForms.CheckInForm die Sie in der Aufrufliste sehen können. Das ist eine sehr einfache Implementierung von ICheckInForm (die relavant-Schnittstelle) und einfach erstellt CheckInForm und Delegierten zu. Es ist nur, weil ich Burg windsor verwenden und Klassen für Verkabelung, die erben von Form schrecklich chaotisch wird. In jedem Fall ist der komplette Inhalt dieser Methode folgt aus:

public void Reset() {_form.Reset();}

Und hier ist die Aufrufliste:

Function: DriverInterface2.UI.WinForms.CheckInForm.Reset(), 
Thread: 0xA96F4 Main Thread, 
Caller: DriverInterface2.UI.WinForms.NonInheritingForms.CheckInForm.Reset, 
Callstack:  DriverInterface2.UI.WinForms.dll!DriverInterface2.UI.WinForms.CheckInForm.Reset
    DriverInterface2.UI.WinForms.dll!DriverInterface2.UI.WinForms.NonInheritingForms.CheckInForm.Reset
    [Native to Managed Transition]
    [Managed to Native Transition]
    mscorlib.dll!System.Delegate.DynamicInvokeImpl
    System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbackDo
    System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbackHelper
    mscorlib.dll!System.Threading.ExecutionContext.runTryCode
    [Native to Managed Transition]
    [Managed to Native Transition]
    mscorlib.dll!System.Threading.ExecutionContext.RunInternal
    mscorlib.dll!System.Threading.ExecutionContext.Run
    System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallback
    System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbacks
    System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc
    System.Windows.Forms.dll!System.Windows.Forms.ScrollableControl.WndProc
    System.Windows.Forms.dll!System.Windows.Forms.ContainerControl.WndProc
    System.Windows.Forms.dll!System.Windows.Forms.Form.WndProc
    System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage
    System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc
    System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback
    [Native to Managed Transition]
    [Managed to Native Transition]
    System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop
    System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner
    System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop
    System.Windows.Forms.dll!System.Windows.Forms.Application.Run
    DriverInterface2.exe!DriverInterfaceRunner.Program.Main
    [Native to Managed Transition]
    [Managed to Native Transition]
    mscorlib.dll!System.AppDomain.ExecuteAssembly
    Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly
    mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context
    mscorlib.dll!System.Threading.ExecutionContext.Run
    mscorlib.dll!System.Threading.ThreadHelper.ThreadStart

Answer 1

Es scheint mir, wie eine Windows-Nachricht an ein .NET-Ereignis vermarshallten wird und dieses Ereignis Ihrer Reset-Methode aufruft. Welches Ereignis es ist, ich weiß es nicht. Wenn es kein Ereignis ist, dann könnte es ein asynchroner Delegate sein.

Wenn Sie Reset-Methode sind von einem Application.Idle Ereignisse aufgerufen wird, das könnte es erklären.

Der Aufruf, der die asynchronen Delegaten führten angehoben (Event-Handler oder anderweitig) wird nicht in dem Stapel erscheint als der Anruf asynchron ist. Daher kann der Stapel von diesem Anruf entwirren, bevor das System, dass die Delegierten über das Windows-Nachrichtensystem sendet. Daher ist der ursprüngliche Anrufer nicht mehr vorhanden in dem Stapel.