Building Graphical User Interfaces (GUIs)

This page covers the basics of GUI development regardless of the platform on which you are working.
Refer to the Code Vault for examples of code.

GUI Programming Basics

The basic underlying approach to GUI programming is quite different from programming done for console applications. Console appliations are those run from a command line (a DOS prompt window on a Windows platform) and have no graphical interface. For these programs the execution paradigm is quite simple (figure 1). The program starts. The program does something, then the program terminates.


The organization of a GUI program is quite different. There are basically two parts to a GUI program: (1) The initialization and set-up section, and (2) the event handler section.

Initialization and setup

In your main function you will:
  1. Do any initialization of data structures, class instantiation, variable value setting, etc. that may be needed.
  2. Build the GUI. This means to instantiate and place all the widgets (windows, dialog boxes, panels, buttons, radio buttons, sliders, scroll bars, text fields, text areas, etc.)
  3. Define what events each widget will handle.
  4. Define a handler function for each event. These functions are called callback functions because the operating system uses them to "call back" to your program when there is an event for the widget to handle.
  5. Register the callback function(s) with the operating system. This involves passing a pointer to the function(s) to the operating system. There is usually a strictly controlled format for a callback function. That is it must take a single argument, which is usually a pointer to an "event message" structure. It must also returned a specific value type to the operating system after handling the event.
  6. Make the GUI (application window(s)) visible.
  7. Return control to the operating system. This means the program, essentially, exits from main().

Event Handling

In a normal console application when you exit from main() (the last step mentioned above) the application terminates. But in a GUI application the program does not terminate. The opeating system continues to process all events from the mouse and keyboard. It is able to determine when an event is meant for your application, e.g. the user clicks somewhere in your application's window. When the operating system determines that a particular event is one that is meant for your application it packages up the information about that event in the appropriate "event message" structure and passes it to your application. Your application will then...
  1. Take the message passed to it from the operating system, or depending on the operating systems procedures, pop the next message from the application's event queue.
  2. Check to see what type of message it has received.
  3. Pass the message information to the appropriate code designed to handle such a message.
  4. Return control to the operating system and wait for the next message to arrive in the queue.

Event Driven Programming

Everyone who has used a computer that was built after the mid-1980s knows what a Graphics User Interface (GUI) is. You start a program by double clicking its icon in a window or selecting it from a popup menu. You then interact with the program by moving the mouse, clicking with the left, middle, or right buttons, and by typing at the keyboard. With other programs you may use a joystick or some other device connecting to the computer.

Every time you do something with one of these devices you are generating Events. Press a key on the keyboard and you generate a key pressed event. Release the key and you generate a key up event. Move the mouse and you generate a series of mouse moved events. Press the left mouse button and you generate a left mouse down event. Continue to move the mouse while the button is pressed and you generate a series of mouse dragged events. Release the mouse button and you generate a left mouse up event. And, on and on it goes.

Everytime you generate an event the operating system creates an event message and passes that message to the appropriate program to handle it. If a program has window with a text box on it and you click in the text box then type something the program get a series of event messages which it must handle. As it handles these messages it will also update and redraw the window as needed to reflect the user's interactions with the program.

This concept of events being generated by a user, and event messages being passed to the program for handling is the basic for all GUI programming regardless of what language you are programming in or what platform you are programming on.

It's the same everywhere

The basic ideas behind GUI programming are the same regardless of whether you are programming on a Windows, Macintosh, Linux, Sun-OS, X-Windows, or Java platform. If you are interested in developing GUI programs which will run on any of these platforms then you should go to the web page for CS 103 Introduction to Programming with Java. The remainder of this page will focus on GUI programming for a Microsoft Windows platform.

Programming In Microsoft Windows

There are three ways you can create GUI programs on a Windows platform:
Using Windows API
Using Microsoft Foundation Classes
Using Windows Forms
Using the Windows API (Application Programming Interface) is the most difficult because you are making calls directly to operating system functions. But, this is also the simplist and easiest to see what is going on. The Microsoft Foundation Classes (MFC) are just C++ class wrappers around the API. Window's Forms is a whole different ballgame.

Windows Forms and the .NET Framework

Some time in 2000 Microsoft introduced its' new runtime environment which it dubbed .NET (pronounced "Dot-Net" in case you have been lost in some cave since then.) The .NET environment consists of two elements:
In a Windows environment then, you can write programs either using the native C++ which is ANSI Standard C++ and makes calls directly to operating system functions (API or MFC programming) or you can use what Microsoft calls C++/CLI (Common Language Infrastructure). This is a CLR program that uses Microsoft's extension to the C++ language. There is a slight disadvantage to using Windows Forms and the .NET Framework. There is a small performance hit but you probably won’t notice this in the majority of applications, unless they are heavily graphics oriented.

BTW CLI is essentially a Virtual Machine environment. Programs compiled to run in this environment on a Windows platform are compiled to a language referred to as Microsoft Intermediate Language (MSIL). This intermediate language is then mapped to machine code while the program runs by what is called a Just-In-Time (JIT) compiler. This intermediate code can also run on any platform that implements the Microsoft CLI language.

Interesting that this is exactly the way Java is implemented. Microsoft essentially copied the Java runtime environment idea. But, then again, Microsoft's C# programming language is nothing but a "reorganized" Java that, unlike Java, won't run on any platform, except Windows.

But, enough of the nasty facts of life. Let's get on to GUI programming...

GUI programming IS Object Oriented

One thing you can say for GUI programming, it forces you to think in an Object Oriented paradigm because a GUI is nothing more than a set of object grouped together interacting with each other and with the user. So let's take a minute to look at the most common GUI widgets (a non-technical term that GUI gurus and geeks like to use to refer to any component of a GUI.)

GUI Widgets

The largest of these GUI components is the window which is actually made up of a number of different components. Take a look at the image below of a Windows platform window. This window is for an application that displays a main application window in which can be displayed a number of "document" windows. Just so you can "speak GUI" you should become familiar with all the terms. These are fairly common across platforms even if the components (like the minimize, maximize, and close buttons) are displayed in different locations.

Note that when it comes to specifying locations for window parts the location of the window itself is given in screen coordinates as pixels from the upper left corner of the screen. Within a window the location of a widget is given in pixels from the upper left corner of the window client area.


The image below illustrates some of the more common types of widgets that you may create and place on a GUI. These are the most common widgets, but this is far from an exhaustive list of what is available.


Menubars, Menus, menu items, and sub-menus are a separate set of widgets that can be added to a GUI to control many aspects of a program.