notes event driven programming and gui applications

Development Software 2 – DOS200S

Compiled By WH. Olivier ©2013 Cape Peninsula University of Technology

Window Form Applications Using Visual C++

Event Driven Programming

Objectives and Learning Areas: For this Assignment you will be tested on the following areas:

1. What is Event Driven Programming (EDP)

2. How EDP works

3. How to add code to certain events of some controls

4. Understand KeyPressed Events

5. Understand Mouse Events

Introduction While your computer is on and running, there is something happening. It is either on the screen or in the

background. So there are always events taking place during the execution of any application.

To better understand event driven programming, please read the notes on the last page taken from a website

(http://www.husseinsspace.com/teaching/udw/1996/cnotes/chapsix.htm) and explains how even driven

programming works.

Event Driven Programming Illustrated Here is some graphics to illustrate how to add events during design time and how events works during runtime.

Adding an Event on a control during design time The diagram below shows how you can add an event during design time and how to add code to these events. As

can be seen from the Properties Windows, there is a whole range of events that takes place on the button only.

Other controls also have their own set of events. Mouse events are those events that take place while working with

the mouse and how the mouse interacts with the application

http://www.husseinsspace.com/teaching/udw/1996/cnotes/chapsix.htm



Executing an Event during Runtime When the application is executed, the processing (operation) takes place as shown in the diagram below:

Adding code to the Click Even When you want to add code to a control, you would double click on the control during design time. Each control has

a default event that will be generated. For the Button control it will be the Click Event. For the textbox control it is

the TextChanged Event.



Calculate Button Click Event Executed During Runtime When the application is running the code is executed as a particular event takes places. In the case of the above

example, the Button Click event will call the Click method for that particular button.

Keyboard Events During the execution of an application, the user can press shortcut keys to perform certain functions or actions. In

order to alert the current form that a shortcut key will be pressed during runtime, the programmer must set the

KeyPreview property on the Form to true. This will register keyboard events for the controls on the form and for the

form itself.

For example, if you want to alert the application that a certain keyboard key will be pressed during runtime, you first

step is to set the KeyPreview property of the Form1 to true.

Adding a KeyPress event to the Form



C++ - Event-Driven Programming

Introduction

In the classical approach to programming, events happen in a pre-defined sequence. In fact, classical

programmers go the extent of defining programs as sets of instructions that are executed sequentially by the

computer. Of course there are loop and jumps but these are still programmed sequentially. However, there

are times when you want the program to respond to events on its own rather than check diligently for the

event. A typical example is the incorporation of so-called "hotkeys" into a program. In the classical

approach, the programmer has to constantly check for these keys, every time a key is pressed. This means a

lot of extra effort for the programmer and it only gets worse as the complexity of the program increases.

An ideal situation would be one where the program responds of its own accord to such events like hotkeys.

It can be done using input filters and other such innovations but if the program is object-oriented,

conversion to event-driven programming is much easier.

Event-driven programming is where the program responds to events rather than follow a sequential course

of instructions. Event-driven programming is especially useful in object-oriented environments and where

graphical user interfaces are being constructed. Most high-level GUI APIs (OWL, MFC, Turbo Vision, etc)

use event-driven programming to embed basic features into every program.

Principles of Event-driven Programming

Firstly, the computer is a sequential device and therefore cannot, on its own accord, respond to events. To

simulate this auto-responding, a kernel must be constructed. This kernel must know about all objects in the

program and must allow communication with these objects.

Events can be defined as any external influence on the computer. Keystrokes are events as are mouse

movements and clicks. Events can also be explicitly sent from one object to another in the form of a

message. These are useful for intra-process and inter-process communication. Idle events can also be

generated automatically by the kernel to allow for background processing.

Lastly, a basic set of objects must be built, following strict guidelines in terms of interfacing with the kernel.

Each top-level object must have the ability to respond to events.

Thus, instead of executing a sequential program, you simply execute the kernel. The kernel will then collect

all events, including various forms of input, and pass it on to the relevant objects for processing.

GUIs

In a graphical user interface, the basic object is usually the window. Windows should therefore be capable

of processing input. Thus they can process events. All descendants of the basic window object must also

have the capability of processing events.

The kernel is normally part of the compiler's libraries (Turbo Vision) or the operating system

(OWL/Microsoft Windows). This kernel provides the basis for all activity on the computer by gathering and

dispatching events.



Event-driven programming lends itself to multi-tasking since the windows do not themselves have the input

focus. The kernel always controls the program and can just as easily control two programs on the screen.

Events can be filtered from one window, where they are not needed, to another where they are. Also, events

can be buffered and processed when the kernel is idle. Since most graphical operating systems are multi-

tasking, their programming APIs are invariably OO and event-driven (eg. OWL, MFC) so as to most

accurately model the OS.

Windows as objects can either be self-regenerative or overlapped. MS-Windows uses the former technique

where every window must be able to redraw itself at any time. Some older text-based GUIs used the latter

technique of each window storing its background - the disadvantage of this is that you cannot change the

window order - advantage is that its easier to program. Each window and other object must process events

as fast as possible. If the event takes long to process, it must be shifted into an internal queue and processed

in the background. This enables cooperative multi-tasking.

Events can be packages into objects where each type of event is identified by a code. Simple GUIs can use

keystrokes to denote events.

The kernel can be run in the background or as the main process. If the kernel is part of the operating system,

it is always stable and cannot be corrupted by incorrect interfacing on the part of the programmer. However,

if the kernel is the main process for the program, all objects created must conform to the interface - this is

essential for cooperative multi-tasking - if one object misbehaves all the others will fail to perform

satisfactorily.

Hussein Suleman

UCT (1996)

http://www.husseinsspace.com/personal.html

http://www.husseinsspace.com/personal.html