GUI Programming and Windows

CS 321 2007 Lecture, Dr. Lawlor

Philosophy

So you need some input from a user. There are at least three ways to do it.

You can cout a little "Please enter your whatever" message, and then cin the data. This is two lines of code, which is nice. But you're also demanding the whatever at that moment--in other words, the program is in control of the interaction. If the user enters something, then the program goes on to demand something else. The user can't tell where they are in the process of running the program, can't go back to fix stuff; the user is not in control.

Or you can bring up a dialog box with a text box, "OK" button, and "Cancel" button. This might be one line of code if you've set things up right. You're still demanding some input from the user at a particular time, but you're giving them an escape route with the "Cancel" button. What do you do if the user cancels? Hopefully something sensible, but you the programmer do have to think about this.

Finally, you can rethink the application--how about providing a big dialog box that includes everything the program will need to get something done. Then the user can enter the stuff in any order, not just the order you bring up the dialog boxes in. The user can see at a glance everything they'll need to run the program. This is actually way better, since the user feels like they're in control. The essence of the Graphical User Interface (GUI) philosophy is "The user is always in control."

Programming Interfaces

There are lots of programming interfaces that let you build GUIs. Here are some of the major ones.

Name	Language	Example	Good Things	Bad Things
HTML	Forms/CGI	Netrun	Super easy--browser does all the hard work	Tough to distribute. Limited interaction (e.g., no custom menus) since browser limits what is possible.
XHTML	JavaScript	Google Maps	Interaction is possible	Still in a browser. Hideous to write. JavaScript slow, poorly implemented, and nonportable.
Windows API	C	Notepad	Standard Windows look and feel	Code runs only on Windows. Simple things can require lots of code.
MacOS Carbon	C	Any Mac Program	Standard Mac look and feel	Code only runs on MacOS. Simple things can require lots of code.
MacOS Cocoa	Objective C	New MacOS X Programs	Interface builder lets you drag-and-drop a GUI	Code only runs on MacOS X. Must write in funky objective C.
X	C	xfig	Runs perfectly across a network.	No code builtin for menus, buttons, scrollbars--you've got to build everything yourself.
GTK	C	GIMP	Nice-looking. Runs (sort of) on all known machines: X, MacOS, Windows	Big. Interface changes pretty fast. Need big library for Windows applications. Looks a bit weird.
Qt	C++	KDE Apps	Nice-looking. Runs well on all known machines: X, MacOS, Windows. Excellent documentation.	Huge. Expensive for commercial use. Free version is only for noncommercial use on Linux.
GLUI	C++	Lawlor Demos	A button takes exactly one line of code. Tiny. Cross-platform.	Many missing features, like menu bars! Looks/acts "weird".
AWT	Java	Java Applets	Real interaction, compiled language. Even compiled code is portable.	Need Java runtime. Tough to put on floppy disk. Can't call old C code. Simple things can require lots of code.
Swing	Java	??	Cool antialiased rendering.	Need latest Java runtime. Tough to mix with AWT.
Win32.NET (Windows.Forms)	.NET	??	Double-clickable .exe file. Easy on Windows.	GUI calls are Windows-specific.
Tk	Tcl	??	Very terse--dialogs are really easy to write.	Tied to Tcl scripting language, which changes pretty quickly. Need to embed Tcl in application.

In this class, we'll be covering the standard Windows interface in detail. It's not a great interface, but it's not too bad, and pretty typical of the sorts of things you see in writing GUI code.

Windows GUI programming

First, you need a compiler. Popular non-Microsoft compilers for Windows include the free command-line Borland compilers, gcc-based command-line Minimalist GNU for Windows (MinGW), Code::Blocks IDE, and BloodShed IDE. But the standard for Windows programming is the Microsoft Visual C++ compilers. The "Visual" has always been something of a misnomer--it's just a normal C++ compiler. The 2003 version is called ".NET" (since the compiler is written using the .NET runtime), but again it accepts plain old C++ like any other compiler.

Visual C++ .NET (Version 7, the 2003 IDE) is installed in the Chapman Lab. The academic version is also available at the UAF tech center for $99.
You can download the "Express" version of the latest Visual C++ 2005 IDE (Version 8) for free from Microsoft; be sure to also get the Windows Platform SDK for "windows.h" and the GUI libraries. Together, these are at least a few hundred meg download.
I've also got a 20MB download with stripped-down command-line versions of the free Version 7 Microsoft compilers and headers. I call it "OrionDev", which you can unzip to C:\Program Files. This doesn't have the ID E, but it's all command-line folks need. It's preinstalled on the images\winXP image on the OS Sampler DVD.

Second, you need documentation on the C++ routines to call.

The MSDN Library is the official Microsoft repository of all API calls. For the most part, it's understandable and there are good hyperlinks--for example, see the documentation for CreateWindow or your event-handling window procedure. But it's slow going, and finding the routine you need can be frustrating.
Win32 Tutorials are a simpler way to learn the basics. I'm not partial to any one tutorial, so just Google it.

Finally, you need some example code. These packages will work with all the compilers listed above, as well as Visual C++ 6. Here's a tiny C-style example program of mine called "mini32".