Main() questions

J

joe_pool_is

Contributor
Joined
Jan 18, 2004
Messages
507
Location
Longview, TX [USA]
The standard Windows form starts with Main().

What is the benefit to starting my application this way:
Code: 
[STAThread]
static void Main() {
  Application.EnableVisualStyles();
  Application.SetCompatibleTextRenderingDefault(false);
  Application.Run(new Form1());
}

as opposed to this way?
Code: 
[STAThread]
static void Main() {
  Application.EnableVisualStyles();
  Application.SetCompatibleTextRenderingDefault(false);
  Form1 form = new Form1();
  form.ShowDialog();
}

Also, I've looked up what a STAThread is (Single Threaded Apartment), but I don't really understand what it is or why I should be using this instead of something else. The help for it says it pertains to applications that use COM interop "if the thread actually makes a call to a COM component."

Huh? Could someone break it down for me?
 
COM objects had some strange issues when dealing with threads and as part of this several different threading models existed, Single Threaded Apartment being one of them.

Windows Forms only really supports COM interop when using this STA model. Even if you are not directly using any COM yourself your application might be indirectly (e.g. clipboard support) so specifying this just removes the potential for problems and should always be included.

The only thing I can imagine different is going to be behind the scenes, IIRC Application.Run pretty much does the same as a normal windows message pump while ShowDialog also performs additional work required by dialog boxes such as pre translating messages. That is a bit of speculation and a bit of looking with reflector.
 
Thank you, sir!

Often I find myself creating a static class to hold a few choice global variables that I want to be accessible throughout the application. It kills 2 birds with 1 stone if I can put it in the Program.cs file, and I can load it before Form1 shows if I design Form1 with some public properties for setting values before it starts.

I just wasn't sure if my apps were missing out of some feature of Windows by calling them with ShowDialog() instead of using Application.Run().

Is there a way to create an instance of my app, set public properties with it, and still use Application.Run() on it?

I've tried passing an active form in the past, and I know that doesn't work. Perhaps I could modify the form's constructor to accept an object (like calling Thread.Start() with a parameter).
 
I don't quite understand. Are you looking to do something like this?
Code: 
[STAThread]
static void Main() {
  Application.EnableVisualStyles();
  Application.SetCompatibleTextRenderingDefault(false);
  Form1 mainForm = new Form1();

[COLOR="DarkGreen"]  // Custom initialization[/COLOR]

  Application.Run(mainForm);
}
Or something else?

Also, I would recommend using Application.Run over ShowDialog. It really probably doesn't matter, but Application.Run is the accepted standard, and it might be doing some initialization (Application class) or cleanup (after the main form closes) that ShowDialog doesn't (it's hard to find clear documentation on the subject).
 
Hi Marble_Eater,

Up until just a day ago, I could have sworn I tried that once before, and it failed because the Application.Run command was wanted a "new Form1()" param.

The only thing I can guess is that I used IntelliSense at some point in the past and noticed that the signature for Application.Run was looking for an ApplicationContext object. Ever since then, it had been learned incorrectly in my mind. I guess I just needed to revisit something I'd learned in the past.
 
Back
Top