Main() questions

27 Jun 2009 6:42 PM

jp2msft

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());
}
[/code]

as opposed to this way?

[code]
[STAThread]
static void Main() {
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Form1 form = new Form1();
form.ShowDialog();
}
[/code]

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?

27 Jun 2009 10:15 PM

Angel_J._HernÃ¡ndez_M.

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

Show quoteHide quote

"jp2msft" <jp2m***@discussions.microsoft.com> wrote in message
news:741FF557-05B8-403C-A5C8-AEBDE91175CC@microsoft.com...
> 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());
> }
> [/code]
>
> as opposed to this way?
>
> [code]
> [STAThread]
> static void Main() {
> Application.EnableVisualStyles();
> Application.SetCompatibleTextRenderingDefault(false);
> Form1 form = new Form1();
> form.ShowDialog();
> }
> [/code]
>
> 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?

28 Jun 2009 5:15 PM

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

Show quoteHide quote

"Angel J. HernÃ¡ndez M." wrote:

> 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
>
>
> "jp2msft" <jp2m***@discussions.microsoft.com> wrote in message
> news:741FF557-05B8-403C-A5C8-AEBDE91175CC@microsoft.com...
> > 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());
> > }
> > [/code]
> >
> > as opposed to this way?
> >
> > [code]
> > [STAThread]
> > static void Main() {
> > Application.EnableVisualStyles();
> > Application.SetCompatibleTextRenderingDefault(false);
> > Form1 form = new Form1();
> > form.ShowDialog();
> > }
> > [/code]
> >
> > 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?
>
>

28 Jun 2009 8:37 PM

Michael Covington

I don't see a reason to do a ShowDialog() on the main form of an app.
You can perfectly well do this:

Form1 f = new Form1();
....do anything you want to the public fields of f...
Application.Run(f);

You can declare anything on f to be public (as opposed to the default,
private) so that you can operate on it from outside the form class.

Is that what you were looking for?

28 Jun 2009 10:58 PM

GÃ¶ran Andersson

jp2msft wrote:

> 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);

--
GÃ¶ran Andersson
_____
http://www.guffa.com

28 Jun 2009 7:29 AM

Tim Roberts

jp2msft <jp2m***@discussions.microsoft.com> wrote:

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

--
Tim Roberts, t***@probo.com
Providenza & Boekelheide, Inc.