Chapter 2: Hello, Windows Forms
2 Hello, Windows FormsThe programs shown in the previous chapter were not, of course, Windows programs. Those programs didn't create their own windows, didn't draw any graphics, and knew nothing about the mouse. All the user input and output came through a class named Console. It's time to move on. For the remainder of this book, the Console class won't be entirely forgotten, but it will be relegated to relatively mundane chores such as logging and primitive debugging.
Which raises the question: What exactly is the difference between a console application and a Windows application? Interestingly enough, the distinction isn't quite as clear-cut as it used to be. A single application can have elements of both. It can start out as a console application and then become a Windows application, and go back to being a console application again. A Windows application can also display console output with impunity. A console application can display a Windows message box to report a problem and then resume console output when the user dismisses that message box.
To the Microsoft Visual Basic compiler, the difference between a console application and a Windows application is a compiler switch named target (which can be abbreviated t). To create a console application, use the switch
That's the default if you specify no target switch. To create a Windows executable, use
The target switch can also indicate a library or a module. In Microsoft Visual Basic .NET, you use the project Property Pages dialog box to set the switch. In the General Common Properties section, set the Output Type to either Console Application or Windows Application.
This compiler switch doesn't do anything very profound. It really only sets a flag in the executable file that indicates how the program is to be loaded and run. If an executable is flagged as a Console Application and is started from Visual Basic .NET or elsewhere in Windows, Windows creates a Command Prompt window that launches the program and displays any console output from the program. If the console application is started from within the Command Prompt window, the MS-DOS prompt doesn't return until the program terminates.
If the executable is flagged as a Windows Application, no Command Prompt window is created. Any console output from the program goes into the bit bucket. If you start such a program from the Command Prompt window, the MS-DOS prompt appears again right after the program is launched.
The point is this: nothing bad happens if you compile a Windows Forms application as a console application!
All the Visual Basic .NET project files that accompany the programs from this book specify that the programs are console applications. That's why when you execute these programs, a Command Prompt window comes up first. That console is to your advantage: if you ever need to see what's going on inside one of these programs, you can simply stick Console.Write or Console.WriteLine statements anywhere in any program in this book. There are very few mysteries in life that can't be cleared up with a couple Console.WriteLine statements. (There's also a Debug class in the System.Diagnostics namespace that provides alternatives to using the Console class for this purpose.)
Of course, I wouldn't send a Windows program compiled as a console application out into the nondeveloper marketplace. Users might get upset seeing a Command Prompt window popping up (unless they are familiar with UNIX and UNIX- like environments). But it's only a compiler switch, and that can be changed at any time.
The real difference between a console application and a Windows application is the way in which the program gets user input. A console application gets keyboard input through the Console.Read or Console.ReadLine methods; a Windows Forms application gets keyboard (and other) input through events, a subject we'll be studying for much of this book.
I created the projects for this chapter in Visual Basic .NET in much the same way I created the projects in Chapter 1. I specified that the project was a Visual Basic Project but that it was an Empty Project. When I created a program in the project, I used the Add New Item menu option and specified a Local Project Item and a Code File. This process dissuades Visual Basic .NET from generating code for you. In this book, you and I will be writing our own code.
However, the Visual Basic compiler needs access to some additional DLLs that are part of the .NET common language runtime (CLR) environment. If you're running the Visual Basic compiler on the command line, you need to include the reference (abbreviated r) compiler switch:
You'll also need to specify these three files if you're compiling from Visual Basic .NET. In Solution Explorer, right-click on the References item underneath the project name and select Add Reference from the context menu. (You can also select the Add Reference item from the Project menu.) Select these three items from the list in the dialog box that you're presented with: