Figure 14 shows a highly simplified view
of the way an application and an application framework work together. The
application framework includes the main event loop and passes events around as
necessary. For example, its HandleUpdate function talks to every TWindow object
and causes it to update by calling its DrawSelf function. The application gets
all of this behavior simply by instantiating TApplication and subclassing
whatever additional classes, such as TWindow, it needs to provide its unique
capabilities. Like a master puppeteer, the application framework pulls the
"strings" provided by the application's subclasses whenever it needs the behavior
they provide.
When you examine the behavior of an application framework with the aid of a
debugger, you see a series of calls to internal framework member functions, with
only the occasional call to your code when the framework calls one of your
object's functions.
The bottom part of Figure 15 illustrates this situation. In a conventional
operating system like the one illustrated in Figure 13, the debugger would show
the opposite arrangement: a series of calls within your code and an occasional
call to a system function, as shown in the top part of Figure 15.
[Contents]
[Previous]
[Next]
Addison-Wesley Publishing Company, Copyright©1995 by Sean Cotter
and Taligent,Inc. All rights
reserved.