Help me parse this column to see what is calling my method
Ok, so I have a very simple form with no presenter controlled logic. There is a public void Reset () method on it that returns the form to its original state. This should only be triggered by the presenter and in very specific cases (like activity timed out). I ran into the problem though on a few occasions (when I simulate my application losing the database connection, for example) the Reset () method gets called when it shouldn't, and I can't figure out what.
So, I set up a trace in the Reset () method and print it out. Oddly enough, this raised even more questions. Can anyone help me figure out where the Reset () call is coming from? My column is below.
One thing I have to explain is DriverInterface2.UI.WinForms.NonInheritingForms.CheckInForm, which you can see in the freeze frame. This is a very simple implementation of ICheckInForm (relavant interface) and just creates CheckInForm and delegates to it. It only exists because I am using a windsor lock and the wiring of the classes that are inherited from the form gets terribly messy. In any case, the full content of this method is as follows:
public void Reset() {_form.Reset();}
And here's the column:
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
source to share
It looks to me like a Windows message is being dispatched to a .NET event and that event triggers your Reset method. What event this is, I do not know. If it is not an event, then it might be an asynchronous delegate.
If you call Reset method from Application.Idle event this might explain it.
The call that caused the asynchronous delegate to be raised (event handler or otherwise) will not appear on the stack because the call is asynchronous. So the stack can untangle this call before the system dispatches this delegate through the Windows message pump. Therefore, the original caller is no longer present on the stack.
source to share