Counter Application displays the value of a counter object in a label. It creates a separate counter class and interacts with it. The application has a menu created from UI Toolkit components which lets the user choose whether to display the counter value in decimal, hexadecimal, or octal.
Both the application and the counter object must file state. The tutorial programs presented before Counter Application are not stateful, that is, they don't have data that the user can change permanendy. Realistic applications must allow users to . change things, so they must file their state.
The application object uses a memory-mapped file to keep track of its state. Using a memory-mapped file avoids duplicating data in both the memory file system in program memory. By contrast, the counter object writes its value to a file when it is saved.
The counter application is described in Chapter 9.
5.1
0.4
z o
~ u :::;
II. II. c:( Z c:( (!)
~
",.. Tic-Tac-Toe
The rest of the tutorial develops a "real" working application, Tic-Tac-Toe. This application is covered in Chapters 10 and 11.
Tic-Tac-Toe presents a tic-tac-toeboard and lets the user write Xs and as on it. It is not a true computerized game-the user does not play tic-tac-toe against the computer. Instead, it assumes that that there are two users who want to play the game against each other.
Although a tic-tac-toe game is not exactly a typical notebook application,
Tic-Tac-Toe has many of the characteristics of a full-blown PenPoint application ..
It has a graphical interface, handwritten input, keyboard input, gesture support, use of the notebook metaphor, versioning of filed data, selection, import/export, option cards, undo support, stationery, help text, and so on.
",.. Template Application
As its name implies, Template Application is a template, "cookie cutter"
application. As such, it does not exhibit much functionality. However, it does handle many "typical" application messages. This aspect makes Template Application a good starting point for building a real application.
",.. Other Code Available
Other source code is provided in the SDK in addition to the tutorial code.
All the source to sample programs is on-disk in \PENPOINT\SDK\SAMpLE. Some of the other sample programs are described in Appendix A of this manual. Excerpts from sample programs also appear and are described in those parts of the
Architectural Reference that cover related subsystems.
5.10.5
5.10.6
5.10.7
Chapter 6 / A Simple
Application (Empty App)
Applications written for many operating systems have to perform housekeeping functions by implementing their own boilerplate code, that is, code that is essentially the same from one application to the next. In PenPoint, the PenPoint Application Framework performs most of these housekeeping functions. By using the Application Framework, you can create an application that can be installed, that can create multiple instances of itself, that can handle page turns, floats and zooms, and that can display an option sheet, all without writing an additional line of code.
Empty Application is a very simple application that does all of these things. The only additional code in Empty Application is a method that responds to
msgDestroy by sending a message to the debug stream (when the program is compiled with the DEBUG preprocessor :fI:define name).
The PenPoint Application Framework is responsible for everything else Empty Application does. Because the Application Framework handles so much of an application's interaction with the system, even such an insubstantial application has substantial functionality.
".. Files Used
The code for Empty Application is in \PENPOINT\SDK\SAMPLE\EMPTYAPP. There are three files in the directory:
EMPTYAPP.C Contains the application class's code and initialization routine
METHODS.TBL' Contains the list of messages that the application class responds to and the associated message handlers to call
MAKEFILE Contains the WATCOMMake file for EMPTYAPP. The make file also defines information required by the OS/2 linker.
".. Not the Simplest
The name Empty Application is not quite accurate, because it isn't totally empty.
You could create an application with no method table at all, that is, one that responds .to no messages at all and relies entirely on clsApp to do the right thing.
Empty Application handles one message by printing a string to the debug stream, so it needs a method table.
6.1
6.1.1
,.. Compiling and Linking the Code
The source code for sample applications is in subdirectories of
\PENPOINT\SDK\SAMPLE. The subdirectory contains a "makefile" that tells
WATCOM Make how to build the application. Thus to compile and link Empty Application, just change directory to \PENPOINT\SDK\SAMPLE\EMPTYAPP and typewmake.
However, you do need to understand what the files are doing, so that you can later modify the makefiles to fit your needs.
These sections describe the actual commands used to compile, link, and stamp EMPTYAPP.
", Compiling Method Tables
. You compile method tables into an object file by running them through the PenPoint method table compiler (in\PENPOINT\SDK\uTIL\CLSMGR\MT.EXE).
By convention, method tables have the suffix .TBL. The control files used by WATCOM Make have a default rule for compiling a method table.
MT produces an object file and a header file for the method table. You use these files when you compile and link the application.
> cd \penpoint\sdk\sample\emptyapp
> mkdir \penpoint\app\emptyapp
> set WCC386=/3s /Oif+ /s /W3 /We /Zc /Zq /fpc /zff /02 /En /OOEBUG
6.2
6.2.1
> \penpoint\sdk\util\clsmgr\mt methods.tbl -Fo=$methods.obj > $methods.err
", Compiling the Application
To compile the application, use the W ATCOM C/386 compiler for protected-mode applicatiofols (WCC386P .EXE).
> set WCC386=/3s /Oif+ /s /W3 /We /Zc /Zq /fpc /zff /02 /En /OOEBUG
> wcc386p /Foemptyapp.obj emptyapp.c > emptyapp.err
"'" Compiler and Linker Flags .
The meanings of the various flags are listed in Table 6-1 (for more information, consult the WATCOM C/386 documentation):
·6.2.2
6.2.2.1
Table 6-1