title: Why is a NullReferenceException thrown when a ToolStrip button is clicked twice - openFileDialog.showDialog()?
body: <p>I created a clean WindowsFormsApplication solution, added a <code>ToolStrip</code> to the main form, and placed one button on it. I've added also an <code>OpenFileDialog</code>, so that the <code>Click</code> event of the <code>ToolStripButton</code> looks like the following:</p>
  
  <pre><code>private void toolStripButton1_Click(object sender, EventArgs e)  
  {  
      openFileDialog1.ShowDialog();  
  }
  </code></pre>
  
  <p>I didn't change any other properties or events.  </p>
  
  <p>The funny thing is that when I double-click the <code>ToolStripButton</code> (the second click must be quite fast, before the dialog opens), then cancel both dialogs (or choose a file, it doesn't really matter) and then click in the client area of main form, a <code>NullReferenceException</code> crashes the application (error details attached at the end of the post). <em>Please note that the <code>Click</code> event is implemented while <code>DoubleClick</code> is not</em>.  </p>
  
  <p>What's even more strange that when the <code>OpenFileDialog</code> is replaced by any user-implemented form, the <code>ToolStripButton</code> <em>blocks from being clicked twice</em>.    </p>
  
  <p>I'm using VS2008 with .NET3.5 on <strong>Windows 7 Professional</strong> (from MSDNAA) with latest updates. I didn't change many options in VS (only fontsize, workspace folder and line numbering).  </p>
  
  <p>Does anyone know how to solve this? It is 100% replicable on my machine, is it on others too?  </p>
  
  <p>One solution that I can think of is disabling the button before calling <code>OpenFileDialog.ShowDialog()</code> and then enabling the button back (but it's not nice). Any other ideas?  </p>
  
  <p>And now the promised error details:</p>
  
  <blockquote>
    <p>System.NullReferenceException was unhandled<br>
         Message="Object reference not set to an instance of an object."<br>
         Source="System.Windows.Forms"<br>
         StackTrace:<br>
              at System.Windows.Forms.NativeWindow.WindowClass.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)<br>
              at System.Windows.Forms.UnsafeNativeMethods.PeekMessage(MSG&amp; msg, HandleRef hwnd, Int32 msgMin, Int32 msgMax, Int32 remove)<br>
              at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)<br>
              at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)<br>
              at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)<br>
              at System.Windows.Forms.Application.Run(Form mainForm)<br>
              at WindowsFormsApplication1.Program.Main() w C:\Users\Marchewek\Desktop\Workspaces\VisualStudio\WindowsFormsApplication1\Program.cs:line 20<br>
              at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)<br>
              at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)<br>
              at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()<br>
              at System.Threading.ThreadHelper.ThreadStart_Context(Object state)<br>
              at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)<br>
              at System.Threading.ThreadHelper.ThreadStart()<br>
     InnerException:  </p>
  </blockquote>