Console applications fit nicely into the batch processing paradigm: take some parameters, do the work, write your progress and/or notices to the console, report an exit code and terminate.  Occasionally, doing the same work in a Windows form provides a better visual interface into the data and activity.

A good example of this is the NT Backup Utility (Programs / Accessories / System).  It can be run in interactive mode, so that the operator creates the configuration, or selects an existing one using the GUI, then launches the backup or restore project with a button.  If that same application is started on the command line with parameters, the backup or restore window starts immediately–and automatically closes when complete.

A Windows Form application in .NET can easily be modified to accept optional command line arguments.  The sample project WinFromWithParameters (see the download page) is a Visual Studio 2008 solution demonstrating how to do it.  The application will display enabled user controls when no parameters are provided, and wait for the operator to change the errorlevel selection and close the form, or press the terminate button.  When parameters are provided, it will display the command-line parameters in the text box, but the textbox and the Test button are disabled.  Instead, a timer is launched with a 5 second interval.  The timer event will close the form and return a specific exit code to the caller.

Things of interest in the code:

  •  The key to making the WinForm see command-line arguments is to add the parameters string[] args to the static void main() declaration, and add the argument args to the Application.Run (Form1()); declaration in Program.cs.  In Form1.cs, the instantiation Form1() becomes Form1(string[] args), and the form now has access to the command-line arguments.
  • If command-line arguments are detected, the code uses a timer to trigger the processing.  It is not a good idea to call your DoWork() method from the Form_Load event.  Windows will continue to render the form and its controls, even after the Form_Load event is complete.  The timer interval is usually set to some small amount (100 ms or so), and the first instruction within the timer event disables the timer from firing again.  Upon entry into the timer event, the application has reached its idle state: when the DoWork() method should be executed.
  • You can control the exit code using the System.Environment.ExitCode property.  The System.Environment.Exit() method will set the exit code, and terminate your application (firing shutdown events) preventing lines after it in the method from executing.  Using the property allows further code to execute, even allowing further overrides of the exit code.
  • The key to executing the Win Form from a batch file, and read its resulting exit code, is to use the START command with the /WAIT option. See the RunDemo.bat file in the project for an example.

Some recommendations for automating WinForms:

  • If you detect arguments, but they have invalid content, don’t inform the users via dialog box, etc.  They probably won’t be there, and your process will hang.  Log the error to an Event Log (Application, etc), and terminate with a specific exit code to semaphore the caller that your app failed.
  • If you update controls on your form periodically, be sure to use the appropriate Application.DoEvents() or.Refresh() methods to ensure the form content is rendered.
  • Sometimes, you have a Windows Form which does a function that you want to automate as part of a batch or other automated sequencing.  If time is sparse, adding command-line parameters to the form can save a lot of refactoring into a new console app, or re-encapsulating functionality into different classes.

WinFormWithParameters is available on the download page.

No Comments
dotNET.Techniques, dotNET.WinForms, Tips and Tricks