Outline of Class 9: Building Graphical Programs

Held: Monday, February 2, 1998

Administrivia

• Today we meet in the MathLAN laboratory. I'm working on moving us to that room, so please look in both rooms the next few days. In general, an outline will be on the wall of whichever room I'm teaching in.
• I have not yet graded assignment one because I was spending my "CS152 time" working on today's lab (I needed to build SimpleGUI). I hope to have them graded for tomorrow.
• There are some problems with SimpleInput. In particular, it doesn't realize that it's at the end of the file when it's also at the end of a line with input data.
  • In the near future, we'll look at a new input class that helps resolve this problem.
  • For now, use a readLine() after reading the last thing you expect on a line.
  • E.g.,

    out.print("Enter the imaginary part: ");
    ipart = in.readDouble();
    in.readLine();
    

• What are some of the points of assignment two?
  • That the descriptions of functions are committments that you must continue to keep, even after you decide to change your implementation. (Hence, you should be careful when thinking what to commit to.)
  • That Java often approximates real numbers, leading to a change in how they appear after a number of related calculations.
  • That Java limits the overloading of function names. For example, you can't have both setValue(double x, double y) and setValue(double theta, double r).
• Most of today's class will be devoted to lab 3. In particular, there are some notes in the outline that we won't discuss explicitly.

Graphical User Interfaces

• Until the advent of the pixel-based monitor, programs were traditionally text-based. That is, programs read sequences of text (or data) and generated similar sequences.
• The use of high-resolution graphics displays, along with pointing devices like mice has permitted the development of so-called Graphical User Interfaces or GUIs (pronounced "gooeys"). Traditionally, GUIs provide windows, menus, and buttons and permit the user to interactively select what to do using those various objects.
• We'll work with a simpler (or is it more general?) view: we'll look at some issues in building programs that draw on the screen and respond to some simple user commands.
• At the heart of most interactive graphical programs are two key concepts:
  • Events
  • The program's responses to those events, which often involve drawing on the screen.
• Java provides a toolkit called the AWT (or Abstract Windowing Toolkit) to simplify the generation of graphical programs. After putting together the various components of a window, you specify how to respond to particular events and what to draw when the system is updated.
• We'll use a sample interface that helps emphasize these two points.

The switch statement

• Often, you need to do more than select between two values, one true and one false.
• While it is possible to do this with a sequence of if statements, such a solution is neither readable nor efficient.
• As an alternative, Java provides the switch statement (like the case statement in Pascal).
• It takes the form

  switch (integer-valued-expression) {
    case value1:
      stuff-to-do;
      break;
    case value2:
      stuff-to-do;
      break;
    ...
    default:
      stuff-to-do;
      break;
  }
  

• If you leave out a break, execution will continue into the next case.
• You can switch on byte, short, int, long, or char valued expressions.
• break has other uses, which you'll see later.

Laboratory: Building Graphical Programs

Refer to the lab handout.