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

      

0


source to share


1 answer


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.

+1


source







All Articles