VisClass: 1 Introduction to VisClass

Up: GEOS SDK TechDocs | Up | Prev: VisClass | Next: 2 The Visible Class Tree

VisClass is one of the three visible classes you'll have to have a working knowledge of in order to use visible objects. Both of the others, VisCompClass and VisContentClass , are its subclasses, and both are important in visible object trees. However, VisClass provides the heart of the visible world.

VisClass objects do nothing useful by themselves. When you subclass VisClass and add your own methods, however, the real power of the visible classes can be used without the programmer having to worry about the nuts and bolts of most UI issues. These classes inherently provide the following features:

Knowledge of Visible Bounds
Every visible object has an instance data field that defines the object's bounds in the GEOS graphic coordinate space. These bounds are used for many purposes, including drawing and input handling. See Positioning Visible Objects .
Comprehensive Visual Updating
When a visible object is included in an object tree displayed by a GenView object, the system automatically tells the object when it must redraw itself. For example, when the view scrolls or when part of the window becomes exposed, the system will send a drawing message through the visible tree; the objects then draw themselves at the proper location in the document space, and the view window is updated. See Drawing to the Screen .
Geometry Management
When visible objects are arranged as children of a VisComp or a VisContent object, they can be set up to update their size and position appropriate to the current window and view context. The VisComp and VisContent classes provide extensive and sophisticated child management functions, though custom management is also allowed and is often used. See Positioning Visible Objects , especially the messages MSG_VIS_RECALC_SIZE and MSG_VIS_POSITION_BRANCH in Geometry Management .
Object Tree Manipulation
VisClass objects can not have children, but they can be children of VisCompClass and VisContentClass objects. All of these classes support extensive tree operations including passing messages up the tree, passing messages down the tree, adding branches, removing branches, and moving branches. See Working with Visible Object Trees .
Mouse Event Handling
When an input event occurs over the GenView window in which the visible tree is displayed, that event is immediately passed on to the VisContent object. The event then travels down the visible object tree (automatically) until it is handled by some visible object. Most often, the event is handled by the leaf object with its visible bounds directly under the mouse pointer. Individual Vis objects can also grab the mouse so that they receive input events that occur even outside their bounds. See both Handling Input and the Input chapter.

Keyboard Event Handling
A visible object can grab the keyboard input stream and receive keyboard events as they occur. Typically, certain keystrokes will be intercepted by the specific UI even if a visible object has the keyboard grab; this ensures the object won't usurp functions expected by the user from his specific UI. (The object can, however, override keystroke interception, though this is strongly discouraged.) See the Input chapter.

Interaction with Input Hierarchies
VisClass objects have an inherent knowledge of the input hierarchies. Many visible objects may need to interact with the Focus and Target input hierarchies especially, and they can also interact with the Model hierarchy as well. See the Input chapter.

Use of VisMonikers
Typically, visible objects will draw themselves in their entirety and will not need visual monikers. Monikers are typically labels attached to objects that get displayed either on or near the object. Visual monikers are most frequently used with generic UI objects, but they can be set up and used with visible objects as well. See Using Visual Monikers .

Standard MetaClass Functions
Because VisClass is a subclass of MetaClass
, it inherits all the basic, standard object functions of that class (e.g., state saving, instantiation and initialization, detaching and destruction, etc.). See the MetaClass chapter.

Many programmers new to object-oriented programming may think that visible objects are used only in certain circumstances. On the contrary, visible objects may be used for nearly any purpose and to provide nearly any application-specific graphical or user interface functions. When used properly, visible objects can relieve you of hours of writing specialized code.

Programmers new to OOP may need to practice with several small applications in order to gain experience using visible objects. You can also study the sample applications, many of which use visible objects extensively.

Visible objects are most useful when you have well-defined items that must appear on the screen or interact with the user. Pieces in a board game provide a good example: Each piece has its own visual representation, and each piece has a special set of behaviors that depend on user actions and game context. Therefore, it makes sense to have each piece be an object of VisClass .

Another, less immediately obvious, example might be a program that represents maps on the screen. The map itself could be stored as a visible composite object ( VisCompClass ), and each of the major subdivisions on the map could be a visible object. For example, in a map of the United States, the country would be a VisComp object, and each state could be a Vis object. Taken one step further, each state could be a composite object, and each county in the state a visible child of the state. Another step turns the counties into composite objects and each town a visible object. This arrangement lends itself to a tree structure, which is how visible objects are stored.

Another example is a spreadsheet application. The spreadsheet itself could be one composite object containing a number of row objects. Each row object is a composite that holds a number of cell objects. Each cell is a visible object with the functions of the cell built into it. The row and spreadsheet composites can use the geometry manager to arrange the cells properly, thereby making the programmer free of ever having to worry where the cells are in the document. The visible object tree will automatically pass input events to the cell under the mouse pointer. Entire rows can be created, destroyed, drawn, erased, or moved with a few simple commands by the programmer.


Up: GEOS SDK TechDocs | Up | Prev: VisClass | Next: 2 The Visible Class Tree