Introduction

 
 
 

FOX Programming.

To illustrate the facility with which you can build a FOX application, we're going to build a few simple FOX applications.  The first application called Scribble.  A picture of the Scribble application is shown below:
 


Fig 1. The Scribble Application.

Scribble demonstrates how to use the FOX Layout Managers, how to create Buttons, and how to handle messages.  Enough talk, lets start coding!  The very first thing is to include the FOX header files.  This is simple, as there is just one thing you need to include:
 

Next, we need an Application object; each FOX application needs exactly one of these.  The basic application object FXApp contains information about the display, as well as a bunch of other stuff needed for running a FOX application.  In this case, as Scribble has only one main window, we make a subclass of this object, and add a few additional member functions and member data for the Scribble application.
  The first line says ScribbleApp is derived from FXApp.  Most classes you will write in the course of programming with FOX are either directly or indirectly derived from one single top level class called FXObject.
The next line line declares a number of member functions which every object derived from FXObject should have; we've used a macro as it is always the same, and more convenient to program this way.

Next, we add some member variables to keep track of the various Widgets, and the drawing color.  We also keep a flag to remember if the mouse was down, and a flag to remember if the canvas is dirty, i.e. has been scribbled on:
 

FOX handles events from the user through a system of messages sent to a certain object.  In this case, the received of the messages is the ScribbleApp class.  Thus, we need to add handler member functions to catch these messages and perform some action in response.  All message handler functions in FOX have the same argument signature:
  Where:
  For the Scribble application, we want  to handle mouse messages, as well as messages from the two buttons:
  ScribbleApp also needs to define some new message ID's.  A message consists of a type and an id.  The type defines what has happened; the id identifies the source of the message.  Even though we know the object that sent us the message, in many cases, we can be sent the same message from different sources, and the id is much more convenient; so:
  We typically define the list of messages some target understands as an enum type.  As the ScribbleApp class is derived from FXApp, it also understands all the messages already understood by the basic FXApp.  Our new messages should have different numbers from those.  Rather than counting by hand, we let the compiler worry about this, by always defining one extra message id with the name ID_LAST, a subclass can simply use the ID_LAST of it's base class to start counting its message id's from; if ever any new message id's are added to the base class, our own messages are automatically renumbered by the compiler.

We wrap up the remainder of the ScribbleApp class declaration by defining a constructor and one member function called create():
 

 In our implementation, the constructor ScribbleApp will actually build the GUI.  The create() function is a virtual function that is called by the system.  Most FOX Widgets have this create function.  FOX Widgets have a two-stage creation process; first, the client side Widgets are constructed, using ordinary C++ constructors.  Then, once the whole widget tree is complete, a single call to the application's create() function will create all the windows for those widgets.  This two step process is needed as the second step may only be executed one the connecion to the display has been established.

Now, we're ready to implement this new class; in most cases, the previous code would reside in a header file, while the implementation would be in a C++ source file, of course.  In the case of ScribbleApp, it is so simple that we placed everything into one file.
The first thing  to do is to define the message map.  The message map is a simple table that associates a message type, and message id to a class's member function.  Having a message map allows us to send any message to any [FXObject-derived] object.
Thus:
 

Note several things about this table; first, there are several messages with the same id, but a different type. Message types indicate what happened, for example, SEL_LEFTBUTTONPRESS means that the left mouse button was just pressed.  The message id identifies the source.  FOX defines a large collection of message types, each of them has a specific meaning.

Next, we need to implement the ``boilerplate'' stuff that the previous FXDECLARE macro has declared:
 

This the first argument of the macro should have the name of the class, in this case ScribbleApp; the second argument should be the name of the class from which the class has been derived; in this case, that's FXApp.  The last to arguments are a pointer to the message map, and the number of messages in that map.  FOX has a convenience macro ARRAYNUMBER() that expands to the number of elements in a compile-time defined array; this makes it easier to add or remove messages.
If the class you're defining implements no additional messages, the last to arguments to FXIMPLEMENT should be simply NULL and 0.

The remainder of the ScribbleApp implementation is pretty much ordinary C++ code.  The constructor follows below:
 

In almost all cases, it takes only one line of C++ code to create a FOX Widget.  Typically, that is a constructor invocation.  As most FOX Widget supply convenient default parameters to the constructor, you may not have to specify most of them.
The first line in the body of the constructor creates a top level window; toplevel windows in FOX have no parent, so pass in a pointer to the application object (this in this case). The remaining parameters are the window title, window decorations (such as resize handles, borders, etc.), as well as the initial size and position.  The initial size and position may be ignored by your particular window manager, they are just hints.
The next line creates a HorizontalFrame Widget.  The HorizontalFrame Widget is a Layout Manager that places its children horizontally.  The MainWindow Widget itself is also a Layout Manager, and the options passed to the HorizontalFrame widgets constructor  determine how it is placed in the MainWindow.

Next, two VerticalFrame widgets are created, one for the drawing Canvas and one for the buttons.  In the canvasFrame, we then place a Label, a grooved Separator, and the Canvas for drawing into.  The Canvas's target object is ScribbleApp (i.e. this), and its message is set to ID_MOUSE.  This causes Canvas to send all its messages to the ScribbleApp object, with the ID set to ID_MOUSE.

Likewise, in the right buttonFrame we place a Label, a grooved Separator, and two Buttons.  The clear button has a caption "&Clear".  The & in front of a latter will cause the Button to install a hot-key Alt-C automatically.  The caption is drawn with the C underlines, as in "Clear."  The target of the clear Button is again the ScribbleApp object, and its message ID is ID_CLEAR.  Likewise, the exit Button sends ID_QUIT.

Note that we didn't have to define ID_QUIT, as this is a message every FXApp object already understands.   Thus, we can simply hook up buttons to their targets.

The remaining arguments to the Buttons determine its frame style (FRAME_THICK|FRAME_RAISED), and how it is placed inside the VerticalFrame Layout Manager (LAYOUT_FILL_X|LAYOUT_TOP|LAYOUT_LEFT) tells the Layout Manager to stretch the Buttons to fill the available room, making them nicely the same size.

Finally, the ScribbleApp constructor initializes its member variables for the drawing color and the flags.

Next, we implement the create() routine:
 

First, we call the base classes' create, then we acquire a red color using acquireColor.  FOX supports a wide variety of displays, including pseudo color displays.  Thus, as FOX has no information about the particular hardware it runs on until a connection with the display has been established, colors need to be acquired in the second phase of the Widget creation process.

Finally, the main window is shown on the screen by calling its show() member function.

Now, we're ready to handle some messages:
 

The first message handler simply sets a flag to remember than the mouse is now down;  the second handler draws a line from the last to the current mouse positions; it then sets a dirty flag to 1 to remember that the Canvas has been drawn onto.  The last handler finishes the line, and resets the mouse down flag.
Nothing remarkable here at all.

The next few message handlers are more interesting:
 

The first message handler clears the canvas, then resets the dirty flag.  The second message handler updates the clear Button.  Each Widget in FOX receives a message during idle processing asking it to be updated.  For example, Buttons can be sensitized or desensitized when the state of the application changes.  In this case, we desensitize the sender (the clear Button) when the Canvas has already been cleared, and sensitize it when it has been painted (as indicated by the dirty flag).

This GUI Update process is extremely powerful:- if an application has N commands, and M Widgets to update for each command, one might have to write NxM update routines; with the GUI Update process, one needs to write only N+M routines.  Moreover, if the application data change by some other means (e.g. timers, external data inputs, mulitple computing threads, etc), the GUI will automatically keep itself up to date without any additional coding.

To complete the Scribble Application, only one thing remains:- to kick it all off from the main() routine:
 

First, we construct a ScribbleApp object, effectively building the whole GUI.  Subsequently, though a call to application->init(), we offer FOX a first chance at the command line arguments of the application; FOX removes those arguments it understands from the argument list, and sets some internal variables from them [For example, the display variable].

Next, we create the application by calling application->create(), and finally we run it.  The run() member function of FXApp never returns until the application is done.
 

Recap.

In the previous example, several FOX features have been discussed:
 



Copyright © 1998 Jeroen van der Zijp, all rights reserved.