Desktop Applications: Programming Graphical User Interfaces

Desktop applications have graphical user interfaces, and these user interfaces are developed in REALbasic graphicallyusing drag and drop to place Controls onto the Window. There are some development tasks in REALbasic that can be accomplished only by using the graphical user interface. One of the most fundamental is dragging controls onto a Window. There is no programmatic way to do this; you must drag it in the Window Layout Editor.

In this section, I will produce the basic shell of the RSSReader application, which will be a desktop application, which means it will have a graphical user interface, or GUI. There are some defining characteristics of GUI applications, one of them being that they use an event-driven paradigm.

Event-Driven Programming

A computer program is a sequence of steps or actions that are taken in a predetermined sequence. Sometimes the particular steps that are taken are conditional upon the state of some piece of information, but the program itself identifies that information, tests it, and responds accordingly. Now, contrast that with a program designed with a graphical user interface. Much of what the program does, it does in reaction to user input. The program does not simply start, execute, and exit in one act. It starts up, does some housecleaning, and then waits for user input for deciding what to do next. The most important distinction is that an event-driven program requires external information to know what to do next.

Event-driven programs use an event loop that constantly looks for information indicating that an event has been triggered. It identifies the type of event and then executes an event handler, which is basically a method that the programmer has written to respond to the event. Bear in mind that user interaction isn't the only way to trigger an event. You can do so programmatically, and one event can trigger another event (called an event cascade), and so on.

This gets to the general concept of events, but there is a lot more to it than that. To come to a better understanding, let's consider for a moment events of other kindsthose that take place in the real world.

The Declaration of Independence begins with the phrase: "When in the course of human events...." It goes on to say (generally speaking) that when certain conditions are met, a series of new events are triggered. In this particular instance, the event being justified was the revolution, and the reason it was justified, they claimed, was because of preceding events. The revolution was triggered by what the revolutionaries claimed were injustices. So this is one concept of an event: it is "triggered" by something. It is contingent upon some state or condition that, when met, causes the event in question to be executed.

Revolutions aren't the only kind of events in the world. There are lots of different kinds of human eventsthings like weddings and birthdays. Many times, we let each other know about pending events by sending an invitation, which provides the basic details about the event: where it's going to be, when it's going to happen, what you need to bring, whether you should RSVP, and so on. In this respect, an event is something that takes place at a certain place, during a certain time, for a particular purpose. It is something that you know about in advance.

There are some events that take place at regular intervals, something that you can predict quite easily. Let's use as an example a high school graduationit happens every year, like clockwork. Everybody knows that graduation is coming and they have an idea of how the ceremony will go, but a lot of planning and details must be attended to in order to pull off any particular graduation. Most importantly, when you receive an invitation to the graduation, you have to decide whether you are going to attend the graduation, what you're going to wear, and what kind of graduation present to buy.

There are other events that are not something planned in advance. This means that they are not triggered by a particular date or time, nor are they triggered by reaching an expected stage in some process. These events are triggered by something unexpected, like an accident in which someone gets hurt. In this case there isn't an invitation that gives you advance noticeyou have to react right away, based on what you know about this unexpected condition.

REALbasic is an event-driven language, and an event in REALbasic works in a similar wayit is code that is executed within an object at a certain time for a particular purpose. For example, every time an application is launched, an Open event is triggeredjust like every year there is a high school graduation. Your job as a developer is to decide what you are going to do in response to the event.

Another common kind of event that REALbasic developers must respond to is user interaction with the MenuBar. When a user selects File, Open, the application must respond to that request. There are some unique characteristics to how these events get handled, and the code you write for them is called a Menu Handler, to distinguish it from the more general-purpose event handlers that you will be writing in other situations.

There are also unexpected events in REALbasic, too. Suppose your application expects to find a file at a certain location, only to find that it's not there, or it finds that the contents of the file are not in the expected format. In those situations, a different kind of event is triggeredone that has its own unique rulesand it is called an exception. Because exceptions are not planned, it is next to impossible to write code at every point in your application to respond to specific errors. Rather than being triggered, exceptions are raised, which is basically a process whereby the exception goes in search of a solution. You will create your own exception types and your own exception handlers when programming in REALbasic.

An event handler is a lot like a method. Like a method, it can be like a subroutine and execute a task when triggered, or it can be like a function and return a value (a Boolean). Also, like a method, events are members of classes, but it is here that the similarities between events and methods begin to disappear, because the normal rules of inheritance and overriding do not apply with events.

Controls and Events

You will probably encounter events most often when working with Controls. Controls are user-interface elements (usuallyas with everything, there are some exceptions) that respond to user interaction, which is why they are so event focused.

One of the goals of modern operating systems is to provide a consistent appearance to the end user. It is much easier to learn a new program if you have a reasonable idea about what to expect when clicking a button or selecting New from the File menu. You have many different programs, but they all share some consistent user-interface elements.

The use of events helps to make that possible. Although the interface for opening a file is the same from the user's perspective, what takes place as a result of that user interaction will vary from program to program. If your program edits text files, when the user opens a file, your program will open the file, get the text, and display it in an EditField. If your program uses files that are formatted as XML, it will need to open the file, parse it into an XMLDocument or something similar, and then display it.

Events are processed differently from overwritten methods. If a class declares an event, that class does not implement the event (unlike when a class declares a method). The event is implemented by either a subclass or a special kind of instance of parent class.

In REALbasic, you can drag a class to a Window, and the result will be a little icon, which you can double-click, representing the class. When you double-click, a Window in the IDE pops up that will allow you to implement the events declared in the class. When you drag an item to a Window, the item is automatically instantiated by the Window when the application runs (it used the default Constructor, with no arguments passed to it). When the events for that instance are called, REALbasic runs the code that was edited from the Window.

When you create a subclass in the IDE (not by dragging it to a Window), you can implement the events that were declared in the parent class. If you subclass the subclass, you will see that the event you implemented in the parent class is not available in the subclass. Unlike methods, events cannot be overridden.

One major difference between events and methods is that when an event is triggered, REALbasic starts looking for an implementation of the event from the top of the class hierarchy, not from the bottom. This means that if you implement an event in a superclass, the event is called in the superclass and it never reaches the subclass.

You can declare a new event in the subclass, which can in turn be implemented in its subclass. However, if you do this, REALbasic will still start from the top of the class hierarchy and traverse it until it finds an implementation of the event, which it will trigger, ignoring any implementations further down the tree. That is, unless you trigger the same event again from the implemented event.

App Events

If you start a new project and double-click the App object so that you can edit it, you will see a label called event handlers listed with the other App members. If the disclosure arrow is closed, click it open and you will see a list of events. If you select one, you can look in the editing area and see the signature for that eventyou'll see that it looks just like a method in many respects.

Events occur at particular stages of your application and when an application first starts, a series of events are triggered. For example, when I launch an application, the following App events occur, in the following order:

App.Open App.NewDocument App.Activate App.EnableMenuItems 

The first event, App.Open, makes sense. It's the event that fires when the application first starts up. The Open event is a good place to do any of the housekeeping necessary to get your program underwaythings like accessing preference files or loading data into memory.

The App.NewDocument event is a little more difficult to understand. Why would a NewDocument event be triggered when the application is just opening? You've no doubt seen some applications that when launched start up with an empty document. In fact, unless you have it configured differently, Microsoft Word launches with an empty, but new, document.

A related event, called OpenDocument, is triggered when the application has been opened as the consequence of a user launching the application by double-clicking a file type associated with the program.

The Activate event is called after the Open and NewDocument event, and it is called every time the application becomes the front-most application on the user's computer. The opposite of the Activate event is the Deactivate event, which is triggered when the application loses its front-most position.

Finally, the EnableMenuItems event is called. This is an event that shows up in the App object, in Windows, and in Controls. There are points along the way in your application when you need to change the state of your menu and make some of the MenuItems active and others inactive. For example, if you have a document open, but it hasn't been changed from the original, there would be no reason for the Save MenuItem to be enabled until the document actually needed saving. So, for example, the EnableMenuItems event is triggered when a user clicks the MenuBar. The EnableMenuItems event is designed to let you manage this process so that when a menu is accessed, only the proper items are available to the user.

There are two Close events that are worth elaborating. Close is the last event to be called, and CancelClose comes right before it. The CancelClose event gives you the opportunity to check to see if users really meant to close the application. This means that generally speaking, you throw up a dialog box of some sort and ask if they really want to quit. If they happen to have any documents with unsaved data, you may prompt them to see if they want to save them. If you return true, the application will not close; otherwise, it will.

Application.CancelClose() as Boolean Application.Close 

AppleEvents are part of the Macintosh environment and are used to add scriptability to your application. Because it is a Macintosh-only feature, I will not dwell on it.

Application.HandleAppleEvent(event as AppleEvent, EventClass as String, EventID as String)as Boolean 

The final event, UnhandledException, is discussed later in the chapter in the section on handling errors. Suffice it to say at this point this is the event that is triggered right before your application crashes, so it's your last chance to fend it off.

Application.UnhandledException(error as RuntimeException) as Boolean