Application.Run vs myForm.ShowDialog

[Bill Burris]

When you crate a Windows application the wizard adds a line like:

Application.Run( new MyMainForm() );

Out of curiosity I replaced this with:

MyMainForm myForm = new MyMainForm();
myForm.ShowDialog();

and run the application with no problem.

Is there any reason why I should use Application.Run instead of
myForm.ShowDialog?

The reason I ask, is I want to place lots of smarts before launching the
GUI. Using agile programming techniques (unit testing, refactoring) I want
to create a functional application before adding the GUI layer. The reason
for doing it this way is that I end up with testable, reusable code, and no
business login in the GUI. Since the GUI is an add-on, the same application
code can be deployed, in a windows app, a service, a web service, a web
form, or console app.

By the way, I added a parameter to the MyMainForm constructor to so that the
GUI code can call back into the objects which get created before the form is
created.

Bill

 

[Alvin Bruney]

When you call show dialog, the run-time will load the application if it is
not running in order to honor the request. If it is running, the request can
be honored immediately otherwise, application run is called. This incurs a
runtime overhead check.

There is no overhead check for the application run event. (well not really,
depending on whether multiple applications can exist, but for the most part
this is true).

 

[Jeffrey Tan[MSFT]]

Hi Bill,

I think the behavior is almost the same with Application.Run and
Form.ShowDialog.
But Application.Run adds an event handler to the mainForm parameter for the
Closed event. The event handler calls ExitThread to clean up the
application.
When Form.ShowDialog is called, the code following it is not executed until
after the dialog box is closed, so you should not place initialize
operation below the ShowDialog method.

Hope this helps,

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

--------------------
| From: "Bill Burris" <[email protected]>
| Subject: Application.Run vs myForm.ShowDialog
| Date: Fri, 17 Oct 2003 16:10:34 -0600
| Lines: 29
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <[email protected]>
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: kzin.phys.ualberta.ca 129.128.162.60
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.csharp:192226
| X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
|
| When you crate a Windows application the wizard adds a line like:
|
| Application.Run( new MyMainForm() );
|
| Out of curiosity I replaced this with:
|
| MyMainForm myForm = new MyMainForm();
| myForm.ShowDialog();
|
| and run the application with no problem.
|
| Is there any reason why I should use Application.Run instead of
| myForm.ShowDialog?
|
| The reason I ask, is I want to place lots of smarts before launching the
| GUI. Using agile programming techniques (unit testing, refactoring) I
want
| to create a functional application before adding the GUI layer. The
reason
| for doing it this way is that I end up with testable, reusable code, and
no
| business login in the GUI. Since the GUI is an add-on, the same
application
| code can be deployed, in a windows app, a service, a web service, a web
| form, or console app.
|
| By the way, I added a parameter to the MyMainForm constructor to so that
the
| GUI code can call back into the objects which get created before the form
is
| created.
|
| Bill
|
|
|