Main() questions

[jp2msft]

The standard Windows form starts with Main().

What is the benefit to starting my application this way:

[STAThread]
static void Main() {
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}

as opposed to this way?

[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?

 

[Tim Roberts]

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."

Some COM objects can only be called from the thread they were created on.
Some COM objects don't care, and can be called from any thread. Objects
that are restricted to one thread live in a "single-threaded apartment".

If you try to call into an object with a different apartment state from the
one you're currently in, COM has to use a proxy to switch over to a
different thread. That's expensive.

When you declare your Main to be [STAThread], you are declaring that your
main thread will be STA. So, if you create any ActiveX objects, it won't
require any proxies. That's usually the safest option.

 

[jp2msft]

Ok, Application.Run is preferred, then, so that I can keep the application's
message loop alive.

I've had times when I wanted to set properties of my forms before they are
loaded, so I'd declare an instance, set the properties, the call ShowDialog.

I'll stick with Application.Run.

Now, can I treat Application.Run like a Thread.Start? Meaning, I can call
Thread.Start with an optional object passed in as a parameter. If I modified
my Form1 constructor to accept an object, could I then call
"Application.Run(new Form1(myObject))"?

This would still allow me to pass in my parameters.

Thanks for helping!
~Joe

Hi there,

The first code fragment, executes a given form as the start object in your
application, I mean, it's the main Window in your App (e.g.: MDI Window or
just a simple window that's displayed when you execute your app). The secode
code fragment, you're setting "some" application attributes (from the UI
perspective) and then display as a Dialog (which is a modal window) the same
Form as before, however you're not calling Application.Run hence the
application message loop doesn't run on the current thread with an
ApplicationContext.

Cheers,


--
Angel J. Hernández M
MCP,MCAD,MCSD,MCDBA
Microsoft MVP
http://msmvps.com/blogs/angelhernandez
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
http://www.customware.net
Tecnical Solutions Architect

The standard Windows form starts with Main().

What is the benefit to starting my application this way:

[STAThread]
static void Main() {
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}

as opposed to this way?

[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?

 

[Göran Andersson]

Now, can I treat Application.Run like a Thread.Start? Meaning, I can call
Thread.Start with an optional object passed in as a parameter. If I modified
my Form1 constructor to accept an object, could I then call
"Application.Run(new Form1(myObject))"?

That has nothing to do with the Application.Run method, actually. It
just takes a reference to a Form object, you can create that reference
any way you like.

For example:

Application.Run(new Form1(any, parameters, you, like));

or:

Form1 mainForm = new Form1(any, parameters, you, like);
mainForm.Any = 1;
mainForm.Properties = 2;
mainForm.You = 3;
mainForm.Like = 4;
mainForm.OrPerhapsCallingAMethod();
Application.Run(mainForm);