CMPT 212 Object-Oriented Applications Design in C++ Fall 1997

Public, Private, and Protected Inheritance (continued)

• Both private and protected inheritance affect how users of a derived class can access members inherited from a base class.

• private and protected inheritance differ in how they affect classes derived from the derived class.

• Example:

     class A {
        public:
           int x;
        protected:
           int y;
        private:
           int z;
        };
  
     class B1 : public A { ... };
  
     class B2 : protected A { ... };
    
     class B3 : private A { ... };
  
     class C1 : public B1 { ... };
    
     class C2 : public B2 { ... };
  
     class C3 : public B3 { ... };
           

  This table shows where the members x, y and z can be accessed:

  	x	y	z
  A member functions	yes	yes	yes
  B1 member functions	yes	yes	no
  B2 member functions	yes	yes	no
  B3 member functions	yes	yes	no
  C1 member functions	yes	yes	no
  C2 member functions	yes	yes	no
  C3 member functions	no	no	no
  A users	yes	no	no
  B1 users	yes	no	no
  B2 users	no	no	no
  B3 users	no	no	no
  C1 users	yes	no	no
  C2 users	no	no	no
  C3 users	no	no	no

Inheriting Friendship

• Friendship is not inherited.
  • Friends of a base class are not automatically friends of a derived class.

Graphical User Interface (GUI) Fundamentals

• In a DOS or other command-line-based application, the application controls when the user can enter input and what input can be entered.
  • When the application wants to do input or output, it call some subroutine in the operating system.

• In a GUI-based application, the application has less control over when the user can enter input and what input can be entered.
  • A user can normally open a menu, resize the window, or close the application at any time.

• Problem: How do we design our application so that we can handle user input at any time?

• Another problem: Normally the user can, at any time:
  • close the application,
  • minimize the application to an icon,
  • maxmize or resize the window, which requires the window to be redrawn,
  • press a key,
  • open a menu,
  • remove a window from in front of the application, which requires the application's window to be redrawn.
  Who (the application or the GUI system) is responsible for handling these events and redrawing the window if necessary?

The GUI System

• The GUI system may be part of the operating system (OS), or may be a separate system running on top of the OS.
  • Part of the OS: MacOS, Windows 95, Windows NT, OS/2.

  • Separate system: Windows 3.x, Unix X/Windows.

• To the user, the GUI is the system that acts as a mediator between the user, the application, and the OS.

• To the programmer, the GUI is a library of constants, variables, types, and functions that allow the application to interact with the user and with the OS.

The Event-Driven Paradigm

• Problem: How do we design our program so that we can handle user input at any time?

• Solution: Use an event-driven paradigm.

• In an event-driven paradigm, the program responds to actions initiated by the user. This is in contrast with the normal (command-line) programming paradigm where the user responds to actions (prompts) initiated by the program.

• In such a program, there is an event loop which receives notification of actions (called events) initiated by the user and call appropriate subroutines.
  • The operation of the loop is this:
    1. get the next event
    2. do appropriate processing
    3. go to 1

• There are two ways that the application can "get the next event":
  1. polling
  2. callbacks

Polling

• With polling, the application calls a subroutine in the GUI system which returns the next event.
  • If there is no event yet, the subroutine waits for one before returning. This is called blocking.

• A true multitasking OS (such as Unix or Windows NT) is required for polling. Otherwise other applications will not have a chance to run while the GUI is waiting for input.

Return to lecture notes index

Lectures