title: Possible to construct form on background thread, then display on UI thread
body: <p>UPDATE: Just to summarize what my question has boiled down to:</p>
  
  <p>I was hoping that constructing .NET forms and controls did NOT create any window handles -- hoping that process was delayed until Form.Show/Form.ShowDialog</p>
  
  <p>Can anyone confirm or deny whether that is true?</p>
  
  <hr>
  
  <p>I've got a large WinForms form with tab control, many many controls on the form, that pauses while loading for a couple seconds.  I've narrowed it down to the designer generated code in InitializeComponent, rather than any of my logic in the constructor or OnLoad.</p>
  
  <p>I'm well aware that I can't be trying to interact with the UI on any thread other than the main UI thread, but what I'd like to do is to have the application pre-load this form (run the constructor) in the background, so it's ready for display on the UI thread instantly as soon as the user wants to open it.  However, when constructing in a background thread, on this line in the designer:</p>
  
  <pre><code>this.cmbComboBox.AutoCompleteMode = System.Windows.Forms.AutoCompleteMode.Suggest;
  </code></pre>
  
  <p>I'm getting the error</p>
  
  <blockquote>
    <p>Current thread must be set to single
    thread apartment (STA) mode before OLE
    calls can be made. Ensure that your
    Main function has STAThreadAttribute
    marked on it.</p>
  </blockquote>
  
  <p>Now this is halfway down the designer file, which gives me hope that <em>in general</em> this strategy will work.  But this particular line seems to be trying to instantly kick off some kind of OLE call.</p>
  
  <p>Any ideas?</p>
  
  <p>EDIT:</p>
  
  <p>I think I'm not making myself clear here.  The delay seems to take place during the construction of a bazillion controls during the designer-generated code.</p>
  
  <p>My hope was that all this initialization code took place without actually trying to touch any real Win32 window objects since the form hasn't actually been shown yet.</p>
  
  <p>The fact that I can set (for example) Label texts and positions from this background thread gave me hope that this was true.  However it may not be true for all properties.</p>