GUI Programming and Windows

CS 321 2007 Lecture, Dr. Lawlor


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.

Good Things
Bad Things
Super easy--browser does all the hard work
Tough to distribute. Limited interaction (e.g., no custom menus) since browser limits what is possible.
Google Maps Interaction is possible
Still in a browser. Hideous to write.  JavaScript slow, poorly implemented, and nonportable.
Windows API
Standard Windows look and feel
Code runs only on Windows.  Simple things can require lots of code.
MacOS Carbon
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.
Runs perfectly across a network.
No code builtin for menus, buttons, scrollbars--you've got to build *everything* yourself.
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.
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.
Lawlor Demos
A button takes exactly one line of code.  Tiny.  Cross-platform.
Many missing features, like menu bars!  Looks/acts "weird".
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.
Cool antialiased rendering.
Need latest Java runtime.  Tough to mix with AWT.
Double-clickable .exe file.  Easy on Windows.
GUI calls are Windows-specific.
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