WO1994023362A1

WO1994023362A1 - Behavior objects

Info

Publication number: WO1994023362A1
Application number: PCT/US1994/003588
Authority: WO
Inventors: Erik Richard Neumann
Original assignee: Kalieda Labs, Inc.
Priority date: 1993-03-31
Filing date: 1994-03-31
Publication date: 1994-10-13
Also published as: AU6419094A

Abstract

An objet oriented programming environment is disclosed. The environment includes a plurality of classes and objects. Each object communicates with other objects in the environment by sending messages which invoke methods in these other objects. The environment contains at least one target object which contains one or more universal methods used for communicating with another object. These universal methods are typically included in all of the target objects in the environment, along with associated universal instance variables used by the universal methods, thereby forming a universal protocol or interface to target objects. Behavior objects, objects that implement the behavior of other objects, obtain and modify properties of the target object by directly invoking the universal methods residing in the target object. Communication between the behavior object and the target object is accomplished through the universal protocol (method and instance variables).

Description

BEHAVIOR OBJECTS

Background of the Invention

The present invention relates to a computer system running in an object oriented programming environment and more particularly to methods and means for associating behavior with objects in the environment.

Authors of computer based multimedia presentations (titles) face the difficult task of creating scripts to control the objects in their title. These scripts, which are essentially a type of computer program, are needed to give these objects the desired behaviors, such as user interface behaviors, animation behaviors, display behaviors, etc. The writing of a script is frequently a complex and time consuming task that demands highly specialized skills. Typically, these skills are hard to come by and very few multimedia authors wish to spend the time to learn them.

Examples of multimedia scripting languages can be found in such computer software program products as HyperCard, developed by Apple Computer, Inc., MacroMind Director, developed by MacroMedia Inc. , and Authorware Professional from MacroMedia, Inc. These multimedia scripting languages require the multimedia author to learn all the intricacies of the scripting language and to develop scripts comprising several hundred lines of code to create desired behaviors. This code is difficult to develop and typically cannot be readily reused.

Further, these languages use a conventional, mostly non-object oriented approach to scripting. It is generally recognized that object oriented approaches have many advantages over non-object oriented approaches, such as the ability to easily reuse code and develop complex code in an efficient manner.

It is currently possible to supply new behavior to objects in object oriented systems. For example, programming systems such as Smalltalk or C++ provide multiple inheritance classes which allow a "mixed in" class to add in new behaviors to an existing parent class.

The object oriented approach of using multiple inheritance to add new behavior allows for reuse of code to some extent, but there are still problems. For example, to mix in behavior, an author typically needs to create a new class in a programming environment, and needs to resolve conflicts for any methods that are defined by both the parent class and the "mix in" class.

The technique of multiple inheritance requires the author to (1) write a new class in order to use the behavior and (2) have the knowledge and skill to resolve the conflicts between the classes. The use of this technique is typically found in programming environments involving compilers, linkers, and debuggers. As a result, this technique can only be learned and used after years of formal training. Thus, the technique of multiple inheritance is typically not available to a non-programmer author in an interactive real time environment where incremental experimentation allows for rapid learning and exploration. Existing environments also do not provide a convenient mechanism for changing the behavior of an object over time while the program is running. The new class always inherits from the mix in class. As a result, the environment can result in a proliferation of confusing and complex classes. Summary of the Invention

Broadly stated, the present invention relates to a system having an object oriented programming environment. The environment includes a plurality of classes and objects. Each object communicates with other objects in the environment by sending messages which invoke methods in these other objects.

The environment contains at least one object (target object) which contains one or more methods (universal methods) used for communicating with another object, such as an object (behavior object) that implements a behavior of the target object. These universal methods are typically included in all of the target objects in the environment, along with associated universal instance variables used by the universal methods, thereby forming a universal protocol or interface to target objects. In order to implement the behavior (e.g., make the target object bounce) , the behavior object must obtain and modify certain properties of that target object, e.g., getting and setting its position. In the present invention, the behavior object obtains and modifies these properties by invoking the universal method(s) residing in the target object. Since the existence and the manner of invoking these universal methods are know at least to behavior objects (e.g., through a published interface or by internal decree of a company or individual) , a behavior object can directly invoke them to obtain and modify these properties.

Significantly, a target object acquires a behavior from the behavior object without having to maintain an inheritance relationship with the class from which the behavior object is derived. Communication between the behavior object and the target object is accomplished through the universal protocol (method and instance variables) . Consequently, the above mentioned problems in the prior art approaches can be avoided.

For example, a "box" object and a "ball" object might contain universal methods for setting their color, position, etc. A behavior object (bounce object) might contain a method (bounce method) for implementing a particular behavior, such as "bounce." This method calculates the position of the controlled target object at the current time. By associating the target object with the bounce object (by means of an explicit command rather than through inheritance) , that object will attain the ability to bounce, i.e., by supplying the information requested and ultimately changing its position and related properties in accordance with the algorithms implemented by the bounce method, using the universal protocol.

It should be noted that traditional principles of object oriented programming dictate that an object's properties and its behavior be contained within the object (either directly or through inheritance) . The present invention circumvents these principles and forsakes the advantages resulting therefrom in order to obtain certain advantages, such as a conceptually simpler authoring environment. The target object may also contain one or more optional methods and related instance variables (optional protocol) relating to other properties of the target object. This optional protocol or interface is also known to behavior object. But, before invoking the optional methods, the behavior object needs to ascertain the existence of these optional methods in its associated target object.

It is an object of the present invention to provide a simple yet powerful programming environment for multimedia authors.

It is a further object of the present invention to reduce the number of classes in an object oriented programming environment.

It is yet another object of the present invention to avoid multiple inheritance in the creation of classes and objects.

It is also an object of the present invention to allow multimedia authors to easily add behaviors to and remove behaviors from an object over time. Other objects, advantages, and features of the present invention will become apparent to those skilled in the art from the following specification when taken in conjunction with the accompanying drawings.

Brief Description of the Drawings

Fig. 1 is a drawing showing an object communication system according to the present invention.

Fig. 2 is a drawing showing the structure of a target object of the present invention.

Fig. 3 is a drawing showing the methods module of the target object of Fig. 2.

Fig. 4 is a flow chart showing the use of the methods module of the present invention. Fig. 5 is a drawing of a computer system containing an object oriented programming environment according to the present invention. Fig. 6 is a drawing showing the communication process between an interpolate object and a target object of the present invention.

Fig. 7 is a flow chart of the communication process between an interpolate object and a target object of the present invention.

Fig. 8 is a drawing showing the communication process between a bounce object and a target object of the present invention. Fig. 9 is a drawing showing target objects in a container in accordance with the present invention.

Fig. 10 is a flow chart of the communication process between a bounce object and a target object of the present invention.

Fig. 11 is a drawing showing a graphic user interface system containing icons in accordance with the present invention.

Detailed Description of Preferred Embodiments FIG. 1 illustrates an object communications system in accordance with the present invention. The system facilitates communications among objects in an object-oriented programming environment. The system of Fig. 1 comprises three classes, class A, class B, and class C, shown as reference numerals 110, 120, and 130, respectively. Each class may consist of an enumerated number of objects which are derived from the class. For example, Fig. 1 also shows an object A derived from class A, an object B derived from class B, an object C derived from class C, and an object D derived from class C; these objects are shown in Fig. 1 as reference numerals 112, 122, 132, and 134, respectively. Each object has the ability to send and receive certain messages in accordance with predefined capabilities of such object. Any particular object of a class may be in communication with one or more objects derived from the same or another class. Direct communication between objects in classes A and B enable object A derived from class A to affect the behavior of object B derived from class B by sending it a specific message. A typical message may be a request for data or information, a transmission of data or information, a query as to the other object's ability to perform certain methods, or an instruction to execute certain operations, to undertake certain actions, or to perform certain functions.

In the preferred embodiment, one of the objects, for example, object A, which is derived from Class A, is a conductor object. The conductor object contains a list of objects that are active and coordinates their use of shared resources, such as a monitor. The conductor is responsible for the smooth updating of the screen of the monitor by compositing the objects on the screen in an efficient way. One of the classes, for example, class B, is a behavior class and objects of class B, such as object B, are called behavior objects. The objects which could be affected by the behavior objects, such as objects C and D, are called target objects. In this embodiment, each behavior object is associated with a single target object, though a target object can be associated with multiple behavior objects.

A significant feature of the object communications system of the present invention is the structure of each target object. Fig. 2 shows a target object 200 consisting of two components: (1) a data field 210, and (2) a methods module 220. Data field 210 contains data that is accessible by methods module 220. Data field 210 is private to target object 200, i.e., it is accessible only by the methods module 220 of target object 200.

The methods module of an object serves as the means by which the object communicates with other objects. The details of methods module 220 of FIG. 2 is depicted in FIG. 3. Methods module 220 consists of a set of methods 222, further divided into a set of universal methods 226 and a set of optional methods 228, and a set of additional methods 224. The universal methods (and their associated instance variables) are, in this embodiment, common to all target objects, i.e., every target object contains the same set of universal methods and instance variables. As a result, a behavior object can send messages to invoke members of the set of universal methods 226. The universal methods 226 are essentially the fundamental functions and operations that all target objects are expected to be capable of performing in response to messages from the behavior objects. Examples of universal methods are methods to determine the position, size, and color of a target object. Universal methods provide consistency and predictability among different objects. A listing of exemplary universal methods and instance variables is given in Table 1.

The set of optional methods (and their associated instance variables) is incorporated in some of the target objects. Thus, in one embodiment a behavior object needs to send messages to determine whether a target object can respond to an optional method before invoking that method. A listing of exemplary optional methods and instance variables is given in Table 2. The additional methods 224 of target object 200 are those methods which are not part of the universal or optional protocol, and thus, cannot be expected to be known to behavior objects. In one embodiment of the present invention, the set of universal methods and instance variables is incorporated in a parent class. The classes which inherit from this parent class contain the universal method and instance variables. Each of these classes may also contain a set of optional methods and instance variables. In other embodiments, the universal methods can be implemented by unrelated classes (i.e., classes not related by inheritance) .

Since the universal and optional methods are known to programmers designing behavior objects, the programmers can create behavior objects which invoke these methods. In the preferred embodiment, a behavior object is designed to be able to invoke only those universal methods or optional methods which are required to implement its behavior. There is no need to include code to invoke universal methods it does not need. As a result, the behavior object can be efficiently designed. The programming considerations in the design of a behavior object are illustrated by flow chart 250 of FIG. 4. If the behavior object wishes to send a message to a target object to invoke a universal method, the behavior object can simply send the message because all the target objects can respond to the message. However, if the behavior object wishes to invoke an optional method in a target object, the behavior object must first determine whether the target object is able to invoke the optional method. Flow chart 250 starts at block 252. The first step is to determine whether a method the behavior object wishes to invoke is a universal method (block 254) . If the answer is positive, indicating that the method is a universal method, the behavior object can send a message to the target object to invoke the method (block 256) . Flow chart 250 is then terminated (block 258) . If the answer responding to block 254 is negative, indicating that the method is an optional method, the behavior object needs to send a message to the target object to determine whether the target object contains the method (block 260) . If the answer responding to block 260 is positive, indicating that the target object contains the optional method, the behavior object can send a message to the target object to invoke the method (block 256) . If the answer responding to block 260 is negative, indicating that the target object does not contain the optional method, the target object does not invoke the optional method. Flow chart 250 is terminated (block 262) .

As a result of the structure of the target object and the communication process between a behavior object and a target object, a behavior object can affect the behavior of any object

(regardless of the class the affected object is derived from) which incorporates the universal and optional methods.

The ability to invoke the universal and optional methods enables the behavior object to affect the behavior of a target object without the need to use multiple inheritance. As a result, the technique of the present invention avoids burdensome overhead or conflicts associated with the process of generating multiple inheritance under traditional object-oriented systems. Multiple inheritance under a traditional objected- oriented system involves the creation of a new class of objects each time it is necessary to generate an object that has some characteristics of one class and some other characteristics of another class. The process of generating a new third class to achieve multiple inheritance often requires significant overhead caused by the complexity of the programming language and the potential conflicts between the specifications and requirements of the two parent classes.

The incorporation of a set of universal methods (and if appropriate, optional methods) in the target objects eliminates the need to generate a new third class of objects since objects can directly communicate with and affect the behavior of one another. The design provides for efficient use and reuse of complex code. For instance, if a behavior object desires to invoke the universal method of another object, the behavior object can safely assume that the target object has the capability to perform the desired universal method. In such instance, the behavior object need not undergo the tedious process of sending a query and receiving a reply from the target object as to whether it has the ability to perform the desired function.

A discussion of two specific applications of the object communications system of the present invention as used in a multimedia environment will further clarify the embodiments of the present invention. Fig. 5 is a drawing showing a computer system 300 comprising a processor unit 310, a monitor 312, and a pointing device 313 (such as a mouse) . Processor unit 310 preferably contains a central processing unit, memory, and other components for performing digital operations. Processor unit 310 further contains a sound unit 314 for generating audio output. Monitor 320 may display a shape, such as a circle 320, which is a physical property of an object created by an object oriented program. A text window 324 may also co-exist with circle 320. Fig. 5 also shows a cursor 326, the motion of which is preferably controlled by pointing device 313.

For purposes of illustration, two behavior objects, an interpolate object and a bounce object, will be described. An interpolate object is designed to move a target object from one position to another position over a specified amount of time. Given inputs of the identity of the target object, the destination, and the travel time, an interpolate object moves the target object in a smooth motion to the destination in the specified amount of time. A bounce object causes a target object to move at a constant velocity and to bounce upon colliding with another object or with the edges of a container that holds the target object. The process of bouncing may involve a change in velocity and/or a change in horizontal and vertical directions. It is sometimes desirable to add features to the bounce and interpolate objects, such as changing the color of the target object when it enters an area on the screen of the monitor, or making a sound when two target objects collide.

An example of a target object is an oval object which is derived from a class of shapes. Objects from the class of shapes, such as ovals, squares, and lines, display themselves on a monitor. In contrast, behavior objects do not display themselves but rather affect the behavior of the target objects. In the exemplary computer system of Fig. 5, a conductor object, such as object A of Fig. 1, is used to composite the screen of monitor 312. The conductor object maintains a list of active objects. As the state of a target object changes resulting from actions by a corresponding behavior object, such as moving the target object from one point to another, the changes are reflected on the screen once the conductor object updates the screen (for example, by invoking the "draw" method of each active target object) . The conductor object may also invoke a "run" method on the behavior objects, causing them to take appropriate actions to communicate with the target objects they control and implementing the desired behavior. Under other embodiments, the behavior objects might, for example, be free running threads of execution.

FIG. 6 depicts the communications between an interpolate object 600 and an oval object 601. In the course of communicating with oval object 601, interpolate object 600 may send to oval object 601 several messages, including a capability query 602, a position query 604, a move command 606, and a "produce sound" command 608. The capability query 602 is simply an inquiry as to whether oval object 601 can perform an optional method. Interpolate object 600 obtains the requested information immediately after issuing capability query 602. Similar to capability query 602, position query 604 is a request for oval object 601 to supply its position to interpolate object 600. Again, interpolate object 600 obtains the answer immediately upon invoking position query 604. Move command 606 is a message from interpolate object 600 instructing oval object 601 to initiate a motion. Similarly, "produce sound" command is a message from interpolate object 600 instructing oval object 601 to produce a sound using sound unit 314, shown in Fig. 5.

Interpolate object 600 also contains a "run" method (not shown) for interacting with the conductor object. Interpolate object 600 performs its calculation and initiates move command 606 or "produce sound" command 608 after the conductor object invokes the "run" method. Oval object 601 also contains a "draw" method (not shown) which can be invoked by the conductor object to draw itself on the screen of monitor 312.

It is possible to associate more than one behavior object with a target object. For example, a color behavior object 610 can be created which changes the color of oval object 601 when it is located within a certain area on the screen of monitor 312. Color behavior object 610 communicates with oval object 601 using a capability query 612, a position query 614, and a color change command 616 in a manner similar to the communication between interpolate object 600 and oval object 601.

Fig. 7 is a flow chart 650 of an interpolate process which implements an interpolate behavior where a sound is produced when the target object reaches the destination. Upon being supplied information regarding the identity of the target object, the destination, and the travel time, interpolate object 600 commences the interpolation process. Interpolate object 600 issues a position query to determine the coordinates of oval object 601 (block 654) . Upon receipt of the coordinates, interpolate object 600 stores the coordinates (block 656) . Interpolate object 600 then goes through a loop comprising blocks 660, 662, and 666. This loop is executed every time the conductor object sends the "run" message to the interpolation object. At block 660, interpolate object 600 calculates the next position for movement by oval object 601 (based on the current time) and stores the next position in memory. Interpolate object 600 then sends a move command (block 662) to oval object 601 to provide it with the coordinates of the next position and to initiate movement toward such position (the oval object will be shown in the next position after it receives the "draw" command from the conductor object) . Interpolate object 600 then determines whether oval object 601 has reached its destination by comparing the coordinates of the current position of oval object 601 with the coordinates of the destination (block 666) . If oval object 601 has not reached the destination, interpolate object 600 will repeat the steps shown in blocks 660, 662 and 666 when it receives the next "run" command. If oval object 601 has reached the destination, interpolate object 600 then initiates the sound production phase of the process. In the preferred embodiment, the conductor object successively invokes the "run" and "draw" methods on active objects such as behavior and target objects. As a result, oval object 601 appears to move steadily towards the destination.

In another embodiment, it is not necessary for the conductor object to repeatedly invoke the "run" method. For example, it is possible for behavior object 600 to execute the steps shown in flow chart 650 in a separate thread.

In the above steps, there is no need for interpolate object 600 to determine whether oval object 601 can respond to the position query and move methods because these methods are known to the programmer to be universal methods. On the other hand, a "produce sound" method is an optional method. Consequently, in block 670, interpolate object 600 sends a capability query to oval object 601 to determine if oval object 601 can execute the "produce sound" method. If oval object 601 cannot execute the method, the interpolate process ends (block 674) . If oval object 601 can execute the "produce sound" method, interpolate method 600 causes oval object 601 to make a sound (block 676) . The interpolate process then terminates.

The flow chart for the interaction between color behavior object 610 and oval object 600, described above, is similar to flow chart 650 of Fig. 7, except that no optional method is involved. It would be obvious for a person skilled in the art to create such a flow chart, and consequently this flow chart will not be shown here.

With respect to the bouncing process, the communication between a bounce object 800 and an oval object 801 is illustrated in FIG. 8. The messages sent between bounce object 800 and oval object 801 are identical to those between interpolate object 600 and oval object 601, as previously discussed. The messages include a capability query 802, a position query 804, and a move command 806. These messages serve the same functions as those corresponding to the communications between interpolate object 600 and oval object 601 as previously described.

Similarly, bounce object 800 and oval object 801 contain the "run" and "draw" methods, respectively.

In addition to being in communication with oval object 801, bounce object 800 must communicate with the environment of oval object 801 to determine the existence of other objects with which oval object 801 may possibly collide. The most common environment containing oval object 801 is the boundary of a monitor's display. However, the oval object may in certain circumstances be bouncing within a local container (i.e., a defined area on the monitor in which objects are confined) . The procedures for bounce object 800 to communicate with the environment will be described in Figs. 9 and 10.

Fig. 9 is a drawing showing two oval objects 832 and 834 located inside a container 830 on the screen 840 of a monitor. Note that container 830 may also move (or bounce) from one position on screen 840 to another, as illustrated in Fig. 9 by line 842 (provided that container 830 implements the required universal methods) .

The primary concern of the bounce object for supplying behavior to its corresponding oval object, for example, oval object 832, is the presence of all the objects, such as oval object 834, within local container 830. The interaction between the bounce object and the container object 830 involves the bounce object sending a list query to container 830 requesting a list of all objects that are contained within the environment of container object 830. Container 830 makes a determination and sends the bounce object a list reply setting forth the identity of all the objects contained therein.

The bouncing process is further clarified by flowchart 900 of FIG. 10. Upon receiving a "run" command from the conductor object, bounce object 800 sends a list query to the container object 830 to determine the presence of any and all active bouncing objects or container boundaries in container object 830 (block 906) . Upon receipt from container object 830 of the list reply setting forth the identity of all bouncing objects or container boundaries within the container, bounce object 800 sends messages to all the objects on the list asking them to determine whether they collide with oval object 801 (block 910) . If there is a collision, bounce object 800 changes the velocity of oval object 801 according to a predetermined formula (block 912) . If there is no collision, the velocity used by bounce object 800 is not changed.

At block 916, bounce object calculates the next position of oval object 801, taking into account whether a collision occurs. Bounce object 800 then sends oval object 801 a move command that specifies the coordinates of the next position and initiates the move by oval object 832 (block 918) . Oval object 801 then displays itself at the new position upon receiving the "draw" command from the conductor object. The steps indicated in blocks 906-918 repeat indefinitely until the bouncing process is terminated.

In many graphical user interface (GUI) systems, a user can use a "drag-and-drop" operation to associate two objects. For example, many GUI systems allow a user to drag an image of a document into an image of a waste basket, instructing the computer to delete the file associated with the document. In the GUI environment of the present invention, graphic images corresponding to behavior objects can be shown on a monitor. A user can associate a target object with a behavior object by dragging an icon representing the corresponding behavior object onto the image of the target object.

Fig. 11 shows a monitor 940 for displaying a GUI system. Monitor 940 displays an icon 944 for a bounce object, an icon 946 for an interpolate object, an icon 948 for a sound object and an image 942 for a target object, such as a menu bar, dialog box, or a box having various shapes. Note that the number and the shape of the icons and target object image are exemplary. A user can associate a bounce behavior with the target object 942 by dragging the icon 944 for the bounce object onto the target object 942. The target object 942 will then bounce with a default velocity. Similarly, a user can drag the icon 946 for the interpolate object onto the target object 942 and then drag the icon 946 to the destination. The target object 942 will then move to the destination using a default velocity. If it is desirable to associate two behavior objects with a target object, such as associating a bounce object and a sound object with target object 942, the user can drag icon 944 onto target object 942 followed by dragging icon 948 onto target object 942. Other behavior objects can also be implemented. For example, a gravity object can be designed to cause a target object being controlled to accelerate toward the bottom of a container. The user can specify the acceleration rate and the target object. Another example is a path object which moves a target object along a given path (e.g., the perimeter of a square or circle) over time. The user can specify the path as a graphic object like "box," "line," or "polygon." The user also specifies the target object, the starting and ending points, and the time it takes to travel along the path.

It can be seen from the above description that behavior objects allow multimedia authors to use complex behaviors developed by skilled programmers very easily, with a minimum of scripting. For the bounce example, the coding for performing bounces is quite complicated, even though writing programs to implement the equations for moving an object from one location to another (taking into account the change in direction in the event of a collision) is within the capability of programmers skilled in the art. Once a bounce object is implemented, the multimedia author may only need to perform a drag and drop or write as little as one line of code — to simply create the bounce object and attach it to the controlled target object. Multimedia authors can, of course, develop their own behavior objects (in whatever scripting or other language is available) , which they can then effectively and easily reuse.

Behavior objects overcome the deficiencies in existing multimedia scripting systems because there is no complex code for the multimedia author to develop, and reuse is very easy. In addition, because the behavior object can often be developed in a more efficient low-level computer language than the typical multimedia scripting language, performance is improved.

Also, behavior objects overcome the deficiencies in traditional object oriented systems with multiple inheritance in several respects. First, a multimedia author does not have to create a new class with its attendant complexities (the author simply creates an instance of the behavior class) . Second, the author does not have to decide how conflicts in methods are resolved, because both the behavior object and the target object have their full set of methods available, and the behavior object can be written to correctly handle any conflicts.

For example, both the behavior object and the target object can get "idle" messages from the system; it does not have to be a case of one or the other getting such an idle message. Another example is a behavior object that gets a mousedown event, and then can decide to either process the mousedown on its own, or hand the mousedown event to its target object, or both.

Third, behavior objects can be "hooked up" to target objects at any time during run time. They can also be disconnected from target objects at run time. And multiple behaviors can be hooked up to a single target object, as the author sees fit. This gives the multimedia author the flexibility to experiment and to add or subtract behaviors over time. Fourth, display objects of the same class (e.g., pixmaps) can be hooked up to various different behavior objects. One bitmap might be hooked up to a bounce behavior, while another is hooked up to an interpolation behavior. This keeps classes from proliferating, so that the environment is simpler for the author to comprehend and use, as compared to a multiple inheritance environment where a new class is made for every combination of display type and behavior type.

It should be understood that while the present invention has been specifically set forth and described with reference to the preferred embodiments, it will be readily appreciated by those skilled in the art that many changes in form and detail may be made without departing from the spirit and scope of the present invention as set forth in. the appended claims.

TABLE 1: EXEMPLARY LIST OF UNIVERSAL METHODS AND

INSTANCE VARIABLES

NAME FUNCTION OF METHODS GET CONTAINER get a reference to the object that contains this target object

SET CONTAINER set a reference to the object that contains this target object

GET BOUNDS get the target object's boundaries SET BOUNDS set the target object's boundaries GET OLDBOUNDS get the target object's boundaries when last drawn

GET POSITION get the target object's position (in container's coordinate system)

SET POSITION set the target object's position (in container's coordinate system)

GET HEIGHT get the target object's height (vertical size)

SET HEIGHT set the target object's height (vertical size)

GET WIDTH get the target object's width (horizontal size)

SET WIDTH set the target object's width (horizontal size)

SET HILITE highlights the target object in some way to the user

GET SELECT track the selection status for the target object

SET SELECT set the selection status for the target object

GET DRAGGABLE returns TRUE if target object can be dragged

SET DRAGGABLE set the draggable status of target object

GET DIRTY returns TRUE if actor needs to be re-drawn

SET DIRTY set the dirty status (need to be re-drawn) of target object

DIRECTTOSCREEN display the image to screen, not onto the composite buffer

GET COLLIDER returns TRUE if the target object participates in collisions

GET NEEDSRUN returns TRUE if the target wants periodic tickle message NAME FUNCTION OF METHODS SET NEEDSRUN sets the needsrun status of the target object

RUN periodic message for target object to recalculate its position and other values (animate)

COLLISIONCHECK periodic message to those actors that check for collisions DRAW draw the target object (the target object should also set OLDBOUNDS and clear the DIRTY flag at this time)

GETUPDATERGN get region to update HITCHECKPOINT return the corresponding part code (e.g., DRAGREGION, CONTENTREGION, and CLOSEREGION) of the target object after given a position

MOUSEDOWN ask target object to process a mouse down event

MOUSEUP ask target object to process a mouse up event

MOUSEWITHIN inform target object that the mouse is currently within its area

MOUSELEAVE inform target object that the mouse has just left its area

MOUSENTER inform target object that the mouse has entered its area

KEYDOWN ask target object to process a keydown event

KEYUP ask target object to process a keyup event

REFRESHRGN similar to draw, except that target object is passed a large region that it is responsible for updating

SHOW make the target object visible

HIDE make the target object invisible

OPEN open state (e.g., menus, icons)

CLOSE close state (e.g., menus, icons)

OBJECTCREATED notify the target object that some other object got created

OBJECTDISPOSED notify the target object that some other object got disposed

OBJECTOPENED notify the target object that some other object got opened NAME FUNCTION OF METHODS OBJECTCLOSED notify the target object that some other object got closed

DROP inform target object that an object was dropped on it

CANACCEPT tell whether this target object can accept a drop of the given object

FLYOVER tell that an object is over this target object and may be dropped

INSTANCE VARIABLE: container, bounds, oldbounds, position, height, width, hilite, selected, draggable, dirty, directToScreen, collider, and needsRun.

TABLE 2: EXEMPLARY LIST OF OPTIONAL METHODS AND

INSTANCE VARIABLES

TARGET OBJECT METHOD FUNCTION OF METHOD GraphicActor GET FRAME determine whether the target object is a frame or solid shape

SET FRAME set the target object as a frame or solid shape

GET FORECOLOR get the foreground color SET FORECOLOR set the foreground color GET BACKCOLOR get the background color SET BACKCOLOR set the background color REGIONOF returns equivalent region of the object

GET FILLCOLOR get the fillcolor SET FILLCOLOR set the fillcolor (for filling the shape)

GET INK get the transfer mode: copy, XOR, matte, transparent, etc.

SET INK set the transfer mode

GET PATTERN get the pattern of the object

SET PATTERN set the pattern of the object

GET FRAMETHICKNESS get the thickness of the frame

SET FRAMETHICKNESS set the thickness of the frame

Arc GET ARCANGLE get the arcangle SET ARCANGLE set the arcangle GET STARTANGLE get the start angle

SET STARTANGLE set the start angle TARGET OBJECT METHOD FUNCTION OF METHOD

Line GET ENDPOINT get the endpoint

SET ENDPOINT set the endpoint

GET ARROWS get the arrows

SET ARROWS set the arrows

GET ARROWSIZE get the size of arrow specified in "arrows"

SET ARROWSIZE set the size of arrow specified in "arrows"

OBJECT INSTANCE VARIABLES GraphicActor fillcolor, frame, ink, forecolor, backcolor, pattern, render, and fra ethickness.

Arc startangle, arcangle. Line endpoint, arrows, arrowSize.

Claims

What is Claimed is:

1. A system having a plurality of objects in an object oriented programming environment, said system comprising: a target object having a universal protocol, said target object including a first universal method relating to a first property of said target object, said first universal method accessible by other objects capable of communicating using said protocol; a first behavior object including means for modifying said first property by using said protocol, thereby affecting a first behavior of said target object.

2. The system of Claim 1 wherein said target object further includes a second universal method relating to a second property of said target object, said second universal method accessible by other objects capable of communicating using said protocol, said system further comprising a second behavior object including means for modifying said second property by using said protocol, thereby affecting a second behavior of said target object.

3. The system of Claim 1 wherein said first behavior object is an interpolate object for moving said target object from a first position to a second position.

4. The system of Claim 1 wherein said first behavior object is a bounce object for detecting collisions between said bounce objects and other objects and for modifying the position and velocity of said target object in response to detection of said collisions.