the invention is preferably practiced in the context of an operating system resident on a personal computer such as the ibm ® ps / 2 ® or apple ® macintosh ® computer . a representative hardware environment is depicted in fig1 a , which illustrates a typical hardware configuration of a workstation in accordance with the subject invention having a central processing unit 10 , such as a conventional microprocessor , and a number of other units interconnected via a system bus 12 . the workstation shown in fig1 a includes a random access memory ( ram ) 14 , read only memory ( rom ) 16 , an i / o adapter 18 for connecting peripheral devices such as disk units 20 to the bus , a user interface adapter 22 for connecting a keyboard 24 , a mouse 26 , a speaker 28 , a microphone 32 , and / or other user interface devices such as a touch screen device ( not shown ) to the bus , a communication adapter 34 for connecting the workstation to a data processing network and a display adapter 36 for connecting the bus to a display device 38 . the workstation typically has resident thereon an operating system such as the ibm os / 2 ® operating system or the apple system / 7 ® operating system . the subject invention is a new object - oriented system software platform comprised of an operating system and development environment designed to revolutionize personal computing for end - users , developers , and system vendors . the system is a complete , standalone , native operating system and development environment architected from the ground up for high - performance personal computing . the invention is a fully object - oriented system including a wealth of frameworks , class libraries , and a new generation object programming environment , intended to improve fundamentally the economics of third party application software development . the subject invention is a fully portable operating system . traditional operating systems provide a set of services which software developers can use to create their software . their programs are very loosely integrated into the overall operating system environment . for example , dos applications take over the entire machine . this means that as far as the user is concerned , the application is the operating system . in macintosh ® and windows operating systems , applications feel and look similar and they typically support cutting and pasting between applications . this commonalty makes it easier for users to use multiple applications in a single environment . however , because the commonalty is not factored into a set of services and frameworks , it is still very difficult to develop software . in the subject invention , writing an &# 34 ; application &# 34 ; means creating a set of objects that integrate into the operating system environment . software developers rely on the operating system for both a sophisticated set of services and a framework to develop software . the frameworks in the subject invention provide powerful abstractions which allow software developers to concentrate on their problem rather than on building up infrastructure . furthermore , the fundamental abstractions for the software developer are very close to the fundamental concepts that a user must understand to operate her software . this architecture results in easier development of sophisticated applications . this section describes four steps to writing software employing the subject invention . a user contemplating the development of an application is typically concerned with the following questions : for a word processor , this is the text i am entering ; for a spreadsheet , it is the values and formulas in the cells . again , for a word processor , the characters are typically displayed in a what - you - see - is - what - you - get ( wysiwyg ) format on the screen with appropriate line and page breaks ; in a spreadsheet it is displayed as a table or a graph ; and in a structured graphics program ( e . g . macdraw ), it is displayed as a set of graphics objects . in a word processing application , a selection is typically a range of characters ; in a structured graphics program it is a set of graphic objects . a command in a word processor might be to change the style of a set of characters to bold . a command in a structured graphic program might be to rotate a graphic object . fig1 b is an illustration of a display in accordance with the subject invention . a command is illustrated at 41 for bringing a picture to the front of a display . a presentation of graphic information is illustrated at 40 . finally , a selection of a particular graphic object , a circle , is shown at 42 . a developer must answer the same four questions asked by the user . fortunately , the subject invention provides frameworks and services for addressing each of these four questions . the first question that must be answered is : what am i modeling ? in a word processing program , the data includes the characters that make up a document . the data in a spreadsheet includes the values and formulas in the cells . in a calendar program , the data includes the times and appointments associated with a given day . the invention provides facilities that help to model data . there are classes for modeling specific data types including : text , structured graphics , sound and video . in addition to these specific classes , the invention provides a number of other abstractions that support problem modeling , including : collection classes , concurrency control , recovery framework , and the c ++ language . the class that encapsulates the data model for a particular data type provides a specific protocol for accessing and modifying the data contained in the data encapsulator , support for overriding a generic protocol for embedding other data encapsulators and for being embedded in other data encapsulators , generating notification to all registered objects when the data changes , and overriding a generic protocol for creating presentations of the data . the next question that must be answered is : how is the data presented ? in a structured graphic program , the set of graphic objects are typically rendered on a canvas . in a spreadsheet , it is typically a table of cells or a graph ; and in a presentation program it is a set of slides or an outline . the subject invention provides a &# 34 ; view &# 34 ; of the data contained in a data encapsulator . the view is created using a &# 34 ; view system &# 34 ; and graphic system calls . however , playing a sound or video clip is also considered a presentation of the data . next : what can be selected ? in a word processing program , a selection is a range of characters ; in a structured graphics program , it is a set of graphics objects ; and in a spreadsheet it is a range of cells . the invention provides selection classes for all of the fundamental data types that the system supports . the abstract baseclass that represents a selection made by a user provides an address space independent specification of the data selected . for text , this would be a numeric range of characters rather than a pair of pointers to the characters . this distinction is important because selections are exchanged between other machines when collaborating ( in real - time ) with other users . the baseclass also overrides a generic protocol for creating a persistent selection corresponding to this selection . persistent selections are subclasses of an anchor object and may be heavier weight than their corresponding ephemeral selections because persistent selections must survive editing changes . for example , a persistent text selection must adjust itself when text is inserted before or after it . anchors are used in the implementation of hypermedia linking , dataflow linking and annotations . the base class also provides an override generic protocol for absorbing , embedding and exporting data contained in a data encapsulator . baseclasses are independent of the user interface technique used to create them . selections are typically created via direct manipulation by a user ( e . g . tracking out a range of text or cells ) but can be created via a script or as a result of a command . this orthogonality with the user interface is very important . baseclasses also provide specific protocol for accessing the data encapsulator . there is a very strong relationship between a particular subclass of the encapsulator class and its subclass of a model selection class . finally : what are the commands that can operate on this selection ? in a word processing program , a command might change the style of a selected range of characters and in a structured graphics program , a command might rotate a graphic object . the subject invention provides a large number of built - in command objects for all of the built - in data types as well as providing generic commands for cut , copy , paste , starting hypermedia links , completing links , navigating links , pushing data on links , pulling data on links , as well as many user interface commands . the abstract baseclass that represents a command made by the user is responsible for capturing the semantics of a user action , determining if the command can be done , undone , and redone . command objects are responsible for encapsulating all of the information necessary to undo a command after a command is done . before a command is done , command objects are very compact representations of a user action . the baseclass is independent of the user interface technique used to create them . commands are typically created from menus or via direct manipulation by the user ( e . g . moving a graphic object ) but could be created via a script . this orthogonality with the user interface is very important . the benefits of plugging into the abstractions in the invention are greater than providing a conceptual model . plugging into the framework provides many sophisticated features architected into the base operating system . this means that the framework implements major user features by calling relatively small methods . the result is that an investment in coding for the framework is leveraged over several features . once a new kind of data is implemented , the new data type becomes a part of the system . existing software that can handle data encapsulators can handle your new data type without modification . this differs from current computer systems , such as the macintosh computer system . for example , a scrapbook desk accessory can store any kind of data , but it can only display data that has a text or quickdraw picture component . in contrast , the subject invention &# 39 ; s scrapbook displays any kind of data , because it deals with the data in the form of an object . any new data type that is created behaves exactly like the system - provided data types . in addition , the data in the scrapbook is editable since an object provides standard protocol for editing data . the scrapbook example highlights the advantages of data encapsulators . if software is developed such that it can handle data encapsulators , an application can be designed to simply handle a new data type . a new application can display and edit the new kind of data without modification . the invention is designed to support multi - level undo . implementing this feature , however , requires no extra effort on the part of a developer . the system simply remembers all the command objects that are created . as long as the corresponding command object exist , a user can undo a particular change to the data . because the system takes care of saving the commands and deciding which command to undo or redo , a user does not implement an undo procedure . a portion of the data encapsulator protocol deals with filing the data into a stream and recreating the data at another place and / or time . the system uses this protocol to implement document saving . by default , a user &# 39 ; s data objects are streamed to a file when saved . when the document is opened , the data objects are recreated . the system uses a data management framework to ensure the data written to disk is in a consistent state . users tend to save a file often so that their data will be preserved on disk if the system crashes . the subject invention does not require this type of saving , because the system keeps all the command objects . the state of the document can be reconstructed by starting from the last disk version of the document and replaying the command objects since that point in time . for reliability , the system automatically logs command objects to the disk as they occur , so that if the system crashes the user would not lose more than the last command . the invention also supports document versioning . a user can create a draft from the current state of a document . a draft is an immutable &# 34 ; snapshot &# 34 ; of the document at a particular point in time . ( one reason to create a draft is to circulate it to other users for comments .) the system automatically takes care of the details involved with creating a new draft . as mentioned above , a document can be reconstructed by starting with its state at some past time and applying the sequence of command objects performed since that time . this feature allows users to recover their work in the case of a crash , and it can also be used to support real - time collaboration . command objects operate on selections , which are address - space independent . therefore , a selection object can be sent to a collaborator over the network and used on a remote machine . the same is true of command objects . a command performed by one collaborator can be sent to the others and performed on their machines as well . if the collaborators start with identical copies of the data , then their copies will be remain &# 34 ; in sync &# 34 ; as they make changes . creating a selection is done using a command object , so that all collaborators have the same current selection . the system uses a feature known as &# 34 ; model based tracking &# 34 ; to perform mouse tracking on each collaborator &# 39 ; s machine . the tracker object created to handle a mouse press creates and performs a series of incremental commands as a user moves the mouse . these commands are sent to collaborators and performed by each collaborator . the result is that each collaborator sees the tracking feedback as it occurs . the system also establishes a collaboration policy . a collaboration policy decides whether users are forced to take turns when changing data or can make changes freely . the invention handles the mechanics of collaboration which removes the responsibility from an application developer . designing a system to manage the sequence of command objects also makes it possible to implement a systemwide scripting facility . the sequence of command objects is equivalent to a script of the local actions . the scripting feature simply keeps track of command objects applied to any document . the scripting facility also uses selection objects in scripts . this feature provides customization of a script by changing the selection to which the script applies . since command objects include a protocol for indicating whether they can apply to a particular selection , the system ensures that a user &# 39 ; s script changes are valid . persistent selections , also known as anchors , can be connected by link objects . a link object contains references to the two anchors that form its endpoints . to the system , the link is bidirectional ; both ends have equal capabilities . certain higher - level uses of links may impose a direction on the link . the single link object supports two standard features : navigation and data flow . a user can navigate from one end of the link to the other . normally , this will involve opening the document containing the destination anchor and highlighting the persistent selection . the exact behavior is determined by the anchor object at the destination end . for example , a link to an animation may play the animation . a link to a database query may perform the query . links also facilitate data flow . the selected data at one end of the link can be transferred to the other end to replace the selection there . in most cases , the effect is the same as if the user copied the selection at one end , used the link to navigate to the other end , and pasted the data . the system takes care of the details involved with navigating from one end of a link to the other ( e . g ., locating the destination document , opening it , scrolling the destination anchor into view , etc .). similarly , the system handles the details of transferring data across the link . the latter is done using the selection &# 39 ; s protocol for accessing and modifying the data to which it refers . the invention supports a system - wide annotation facility . this facility allows an author to distribute a document draft for review . reviewers can attach posted notes to the document , and when done , return the document to the author . the author can then examine the posted notes and take action on each . ( an author can also create posted notes in the document .) a reviewer need not have the same software as the author . instead , the reviewer can use a standard annotation application . this application reads the data from the author &# 39 ; s draft , and creates an annotatable presentation of the data . ( creating such a presentation is part of the standard data encapsulator protocol .) the reviewer can create selections in the document , and link posted notes to the selection . the link between the posted note and selection allows the system to position the posted note &# 34 ; near &# 34 ; the selection to which it refers . the links also make the annotation structure explicit , so that the system can implement standard commands to manipulate annotations . the contents of the posted note can be any data type implemented in the system , not simply text or graphics . the contents of a note is implemented using a data encapsulator , and opening a note results in creating an editable presentation on that data . data representation is concerned with answering the question of what is the data that i am modeling ? the subject invention provides facilities that help to model data . there are classes for modeling specific data types , including : text , structured graphics , sound and video . in addition to these specific classes , the invention provides a number of other abstractions that help to model a problem : the collection classes , the concurrency control and recovery framework , and the c ++ language itself . in the subject invention , the class that encapsulates the data model for a particular data type is a subclass of the encapsulator class . a developer creates a container for a particular type of data representation by creating a derived class of the encapsulator class . for each type of data in the system , ( e . g . graphic objects , styled text , spreadsheet cells ) a different derived class must exist which acts as the container for a type &# 39 ; s data . each class of encapsulator provides a type specific protocol for accessing and modifying the data contained therein . this protocol is typically used by presentations for displaying the data and by commands for modifying the data . in addition to type specific protocol , the encapsulator class provides generic protocol that supports the embedding of data encapsulators as &# 34 ; black - boxes &# 34 ; into other alien types . this protocol must be implemented in the derived class to support the creation of presentations , editors and selections for the encapsulated data . a container need only understand this generic protocol to support the embedding of any alien data type . the data type designer has both the c ++ object model , and a rich set of standard classes to choose from when designing a representation for a particular type of data . the classes provided by the invention should always be considered before designing unique classes to represent the data . this minimizes any duplication of effort which may occur by creating new classes which provide similar or identical function to classes already existing in the system . the most basic of these is the c ++ object model . a designer can create a class or classes which closely match the mental model of the user to represent the classes the user deals with . the invention &# 39 ; s foundation classes provide many standard ways to represent data . collection classes provide a number of ways for collecting together related objects in memory , ranging from simple sets to dictionaries . disk - based collections , providing persistent , uncorrupted collections of objects , are also available . a data type requiring two ( 2d ) and three dimensional ( 3d ) graphic modeling , such as a graphical editor , is also supported . numerous 2d and 3d modeling objects are provided along with transformation , matrix classes and 3d cameras . similarly , the invention provides a sophisticated text data type that supports full international text , aesthetic typography , and an extensible style mechanism . the invention also provides support for time based media such as sound and video . sophisticated time control mechanisms are available to provide synchronization between various types of time based media . the encapsulator class provides a protocol for the creation of various classes of presentations on the data contained within the encapsulator . the presentations include a thumbnail presentation , a browse - only presentation , a selectable presentation , and an editable presentation . there is also a protocol for negotiating sizes for the presentations and fitting the data into the chosen size . subclasses of the encapsulator class are responsible for overriding and implementing this protocol to support the embedding of the data in other encapsulators . the presentations currently supported include : thumbnail -- this presentation is intended to give the user a &# 34 ; peek &# 34 ; at what is contained in the encapsulator . it is typically small in size and may scale - down and / or clip the data to fit the size . browse - only -- this presentation allows the user to view the data in its normal size but the user is unable to select or modify any of the data . selectable -- this presentation adds the ability to select data to the capabilities provided by the browse - only presentation . it is used in annotating to allow annotations to be tied to selections in the data without allowing modification to the data itself . the selectable presentation is typically implemented as a subclass of the browse - only presentation . editable -- this presentation adds the ability to modify data to the capabilities provided by the selectable presentation . this is the presentation that allows the user to create new data and edit existing data . currently , this presentation provides its own window for editing . it is likely that in the future support will be added for presentations which allow editing in place . the editable presentation is typically implemented as a subclass of the selectable presentation . when the data contained in an encapsulator class is changed , it is necessary to provide clients ( e . g . a view on the data ) with notification of the change . encapsulators rely on a built - in class for standard notification support to allow the encapsulator to notify clients of changes to the data representation . a client can connect to an encapsulator for notification on specific changes or for all changes . when a change occurs the encapsulator asks the model to propagate notification about the change to all interested clients . this section addresses how the system presents data to a user . once the data has been represented to the system , it is the role of the user interface to present the data in an appropriate and meaningful way to a user . the user interface establishes a dialogue between the user and the model data . this dialogue permits a user to view or otherwise perceive data and gives a user the opportunity to modify or manipulate data . this section focuses on data presentation . a developer creates a class to facilitate the presentation of data to interact with a data encapsulator . by separating the data model from the presentation , the invention facilitates multiple presentations of the same data . some applications , like the apple ® macintosh finder , already support a limited form of multiple presentations of the same data . sometimes it is useful to be able to display different views of the same data at the same time . these different views might be instances of the same class -- as in a 3d cad program which shows four different view of the same data . for each kind of presentation , a user was previously required to write a view which can display the model and a set of trackers and tracking commands which can select and modify the model . the simplest presentation type is the name of the data . the name is a text string that indicates the data content or type . examples include &# 34 ; chapter 4 &# 34 ;, &# 34 ; 1990 federal income taxes &# 34 ;, &# 34 ; to do &# 34 ;. another simple presentation type , an icon , is a small graphical representation of the data . it usually indicates the data type . examples are a book , a report , a financial model , a sound or video recording , a drawing . however , they may also display status , such as a printer that is printing , or indicate content , such as a reduced view of a drawing . finally , the thumbnail , is a small view of the model data . this view may show only a portion of the data in order to fit the available space . examples are a shrunken drawing , a book &# 39 ; s table of contents , a shrunken letter , or the shrunken first page of a long document . a browse - only presentation allows a user to view the data in its normal size but the user is unable to select or modify any of the data . selectable presentations allow a user to view , explore , and extract information from the data . these presentations provide context : what the data is , where the data is , when the data was . it may help to present the data in a structured way , such as a list , a grid , as an outline , or spatially . it is also useful to display the relationships among the data elements , the data &# 39 ; s relationship to its container or siblings , and any other dependencies . selectable presentations may also display meta data . an example is the current selection , which indicates the data elements a user is currently manipulating . another type of meta data is a hypermedia link between data elements . the view may also indicate other users who are collaborating on the data . selectable presentations are usually very specific to the type of the data . they are made up of windows , views , and other user interface objects which may be customized to best reflect the data type . some examples are : sound recording -- a control panel would facilitate an audible presentation . views would display the sound as a musical score or as a series of waveforms . views may include a sample number or time indications . financial model .-- the model could be viewed as the set of formulas and other parameters . it could display values from the model at a particular instance of time or with specific input values as a spreadsheet or in various graphical forms . book .-- the model could be viewed as a table of contents , an index , a list of illustrations . it could be viewed as a series of pages , a series of chapters , or a continuous text flow . video recording -- the model could be viewed as a series of individual frames or as a continuous presentation . views may include track marks , frame number , and time indications . container containing other objects -- the objects could be displayed alphabetically by name , by type or other attribute , as a set of icons , as a set of thumbnails . editable presentations are similar to interactive presentations except that they also facilitate data modification . they do this by allowing direct manipulation of the data with the mouse or other pointer . they also allow the data to be manipulated symbolically through menu items and other controls . presentations interact with data encapsulators in order to determine the data and other information to present . presentations query the model for the data that is required . the presentation may present all or only part of the data that is contained or can be derived from the data in the data encapsulator . because there can be many presentations of a single model active at once , the data can be changed from many sources , including collaborators . each presentation is responsible for keeping itself up to date with respect to the model data . this is accomplished by registering for notification when all or a portion of a model changes . when a change occurs to data in which the presentation is interested , the presentation receives notification and updates its view accordingly . change notification can be generated in any of the ways listed below . first , change notification can be generated from the method in the data encapsulator which actually changes the model data . second , change notification can be generated from the command which caused the change . as mentioned earlier , there are benefits to these two approaches . generating the notification from within the data encapsulator guarantees that clients will be notified whenever the data changes . generating the notification from the command allows &# 34 ; higher - level &# 34 ; notification , and reduces the flurry of notifications produced by a complicated change . the notification framework provides a mechanism for propagating change information between objects . the framework allows objects to express interest in , and receive notification about changes in objects on which they depend . a standard interface is provided for classes that provide notification to clients . notifier classes provide notification source objects with the means to manage lists of clients and dispatch notifications to those clients . notifier objects require no special knowledge of the class of objects receiving notifications . connection objects provide the dispatch of notifications from the notifier to specific notification receiver objects . these connection objects allow specialization of how notifications are delivered to different classes of receivers . finally , notification objects transport descriptive information about a change , and interests describe a specific notification from a notification source object . fig1 is an object generating notification flowchart for a notification source object . processing commences at terminal 1800 and immediately passes to function block 1810 where a notification receiver object creates a connection to itself . then , at function block 1820 the notification receiver object adds appropriate interests for one or more notifications from one or more notification source objects . these interests are defined by the notification source object ( s ). the client object asks the connection object to connect to the notification source ( s ) for notifications specified by the interests in the connection in function block 1830 . then , in function block 1840 , for each interest in connection , the connection is registered as interested in the notification with the notifier in the interest . next , at function block 1845 , the system enters a wait state until a change is detected . when a system change occurs , control immediately passes to 1850 where a notification source object changes and calls notify on its notifier with a notification describing the change . for each connection registered with the notifier as interested in the notification , at function block 1860 , the connection is asked to dispatch the notification . in turn , at function block 1870 , the connection dispatches the notification to the appropriate method of the notification receiver . finally , at function block 1880 , the notification receiver takes the appropriate action for the notification , and a test is performed at decision block 1885 to determine if another connection is registered with the notifier as interested in notification . if there is another connection , then control passes to 1850 . if there is not another connection to service , then control passes to function block 1845 to await the next change . data specification addresses the selection issue of data processing . if a user must manipulate data contained in a representation , the data must be able to specify subsets of that data . the user typically calls this specification a &# 34 ; selection ,&# 34 ; and the system provides a base class from which all selection classes descend . the invention also provides selection classes for all of the fundamental data types that the system supports . the object which contains the specification of a subset of data in a representation is a model selection class . in the case of a text representation , one possible selection specification is a pair of character offsets . in a structured graphics model , each shape must be assigned a unique id , and the selection specification is a set of unique ids . neither of the specifications point directly at the selection data and they can be applied across multiple copies of the data . a selection understands the representation protocol for accessing and modifying data and knows how to find data in a local address space . command objects access a representation &# 39 ; s data through data selection , and therefore require no knowledge of converting from specification to the real data in the local model . it is the job of the selection object to provide access to the real data from the address space independent specification . in a text encapsulator , this processing may require querying the encapsulator for the actual characters contained in a range . in a base model such as a graphical editor the selection will typically hold surrogates for the real objects . the encapsulator must provide a lookup facility for converting the surrogate to the real object . the model selection class provides a protocol for the exchange of data between selections . by implementing the protocol for type negotiation , absorbing , embedding and exporting data , derived classes provide support for most of the standard editing commands . this means that the editing commands ( cut , copy , paste , push data , etc .) provided by the system will function for the represented data type and will not require reimplementation for each application . the model selection class also provides support directly for the exchange of anchors and links but relies on the derived class &# 39 ; s implementation of several key methods to support the exchange of the representation &# 39 ; s data : copydata must be implemented by the derived class to export a copy of the specified data . the implementation creates and returns a new data encapsulator of the requested type containing a copy of the specified data . adoptdata must be implemented by the derived class to support absorbing or embedding data into the specification &# 39 ; s associated representation . if the data is to be absorbed it must be of a type which can be incorporated directly into the receiver &# 39 ; s representation . the absorbed data is added to the representation as defined by the specification . it is common for many data types to replace the currently specified data with the newly absorbed data . any replaced data is returned in a data encapsulator to support undo . if the data is to be embedded , the encapsulator is incorporated as a black box and added as a child of the representation . cleardata must be implemented by the derived class to delete the specified data from the associated representation . an encapsulator of the representation &# 39 ; s native type containing the deleted data must be returned . the user interface for creating specifications is typically the responsibility of a presentation on the data . a number of mechanism are available depending on data type and presentation style . the most favored user interface for creating a selection is direct manipulation . in a simple graphics model , objects may be selected by clicking directly on the object with the mouse or dragging a selection box across several objects using a mouse tracker . in text , a selection may be created by as the result of a find command . another common way that selections are created is as a result of a menu command such as &# 34 ; find .&# 34 ; after the command is issued , the document is scrolled to the appropriate place and the text that was searched for is selected . finally , selections can come from a script ( or programmatically generated ) and the result would be the same as if a user created the selection directly . &# 34 ; naming &# 34 ; selections for scripts involve creating a language for describing the selection . for example , in text , a selection could be &# 34 ; the second word of the fourth paragraph on page two .&# 34 ; the invention &# 39 ; s architecture provides support for scripting . data modifications addresses the question : what are the commands that can operate on this selection ? if a user is to modify the data contained in a representation , the system must be able to specify exactly the type of modification to be made . for example , in a word processing program , a user may want to change the style of a selected range of characters . or , in a structured graphics program , a user may desire rotation of a graphic object . all user actions that modify the data contained in a data encapsulator are represented by &# 34 ; command objects .&# 34 ; the abstract base class that represents a command made by the user is the model command object . subclasses of the model command object capture the semantics of user actions , such as : can be done , undone , and redone . these subclasses are independent of the user interface technique used to create them . unlike macapp , as soon as the semantics of a user action is known , device events are translated into command objects by the system . creating a new class of command involves overriding a number of methods . the most important three methods to override are : handledo , handleundo and handleredo . the handledo method is responsible for changing the data encapsulator appropriately based on the type of command that it is and the selection the command is applied to . for example , if the command involves a style change to a range of characters in a word processor , the handledo method would call a method ( or set of methods ) in the data encapsulator to specify a character range and style to change . a more difficult responsibility of the handledo method is saving all of the information necessary to &# 34 ; undo &# 34 ; this command later . in the style change example , saving undo information involves recording the old style of the character range . the undo information for most commands is very simple to save . however , some commands , like find and change may involve recording a great deal of information to undo the command at a later time . finally , the handledo method is responsible for issuing change notification describing the changes it made to the data encapsulator . the handleundo method is responsible for reverting a document back to the state it was in before the command was &# 34 ; done .&# 34 ; the steps that must be applied are analogous to the steps that were done in the handledo method described above . the handleredo method is responsible for &# 34 ; redoing &# 34 ; the command after it had been done and undone . users often toggle between two states of a document comparing a result of a command using the undo / redo combination . typically , the handleredo method is very similar to the handledo method except that in the redo method , the information that was derived the last time can be reused when this command is completed ( the information doesn &# 39 ; t need to be recalculated since it is guaranteed to be the same ). command objects capture the semantics of a user action . in fact , a command represents a &# 34 ; work request &# 34 ; that is most often created by a user ( using a variety of user interface techniques ) but could be created ( and applied ) in other ways as well . the important concept is that command objects represent the only means for modifying the data contained in a data encapsulator . all changes to the data encapsulator must be processed by a command object if the benefits of infinite undo , save - less model , and other features of the invention are to be realized . the most favored user interface for issuing commands involves some sort of direct manipulation . an object responsible for translating device events into commands and &# 34 ; driving &# 34 ; the user feedback process is known as a tracker . the invention provides a rich set of &# 34 ; tracking commands &# 34 ; for manipulating the built - in data types . for example , there are tracking commands for rotating , scaling and moving all the 2d objects in pink such as lines , curves , polygons , etc . a common user interface for issuing commands is via controls or the menu system . menus are created and a set of related commands are added to the menu . when the user chooses an item in the menu , the appropriate command is &# 34 ; cloned &# 34 ; and the do method of the command is called . the programmer is never involved with device events at all . furthermore , because commands know what types of selections they can be applied to , menu items are automatically dimmed when they are not appropriate . finally , commands can be issued from a script ( or programmatically generated ) and the result would be the same as if a user issued the command directly . the pink architecture provides support for scripting ; however , at this time , there is no user interface available for creating these scripts . the invention provides a large number of built - in command objects for all of the built - in data types as well as providing generic commands for cut , copy , paste , starting hypermedia links , completing links , navigating links , pushing data on links , pulling data on links , as well as many user interface commands . one of the advantages of using the frameworks is that these built - in command objects can be used with any data encapsulators . the previous sections of this document concentrated on the foundational features of the invention . there are many additional facilities in the invention that implement advanced features . specifically , these facilities include : model - based tracking , filing , anchors , and collaboration . tracking is the heart of a direct - manipulation user interface . tracking allows users to select ranges of text , drag objects , resize objects , and sketch objects . the invention extends tracking to function across multiple views and multiple machines by actually modifying the model . the tracker issues commands to the model , which posts change notifications to all interested views . model based tracking is the best solution for tracking in documents , but it does have the drawbacks that : ( 1 ) the model &# 39 ; s views must be optimized to provide quick response to change events and ( 2 ) the model must be capable of expressing the intermediate track states . persistent selections or &# 34 ; anchors &# 34 ; are very similar to selections in that they are specifications of data in a representation . the difference is that anchors must survive editing changes since by definition anchors persist across changes to the data . the implementation of graphics selections described earlier in the document is persistent . the implementation of text selections , however , is not . if a user inserts or deletes text before a selection , then the character offsets must be adjusted . there are a couple of approaches for implementing text anchors . first , the text representation maintains a collection of markers that point within the text , similar to the way styles are maintained . the anchors include an unique id that refers to a marker . when the text is changed , the appropriate markers are updated , but the anchors remain the same . another approach is to maintain an editing history for the text . the anchor could contain a pair of character positions , as well as a time stamp . each time the text was edited , the history would be updated to record the change ( e . g ., 5 characters deleted from position x at time t ). when the anchor is used , the system would have to correct its character positions based on editing changes that happened since the last time it was used . at convenient times , the history can be condensed and the anchors permanently updated . the system provides a large number of features for &# 34 ; free &# 34 ; through the anchor facility . all of the hypermedia commands ( createlink , pushdata , pulldata , and follow ) all use anchors in their implementation . the implementation of the system wide annotation facility uses anchors in its implementation . the base data encapsulator provides services for keeping track of anchors and links . however , the user is responsible for making anchors visible to the user via presentations . the application must also issue the proper command object when a user selects an anchor . after a user interface for anchors and links is nailed down , the document framework provides additional support to simplify processing . filing is the process of saving and restoring data to and from permanent storage . all a user must do to make filing work is to implement the streaming operators for a data encapsulator . the invention &# 39 ; s default filing is &# 34 ; image &# 34 ; based . when a user opens a document , the entire contents of the document are read into memory . when a user closes a document , the entire contents of the document are written back to disk . this approach was selected because it is simple , flexible , and easy to understand . to store data in a different format , perhaps for compatibility with a preexisting standard file format , two approaches are possible . first , an encapsulator class can stream a reference to the actual data , then use the reference to find the actual data , or a new subclass can be defined to create and return a file subclass . the advantage of the first approach is a data encapsulator can be encapsulated in other documents . the advantage of the second approach is the complete freedom afforded to exactly match an existing file format for the complete document . same - time network collaboration means that two or more people edit the same document at the same time . the system also establishes the collaboration policy ; that is , whether users are forced to take turns when changing the data or can make changes freely . a developer does not have to worry about the mechanics of collaboration or the collaboration policy . to assist in the reduction of confusion and enhance model selection , the document architecture provides a collaborator class which contains information about the collaborator &# 39 ; s initials and preferred highlight bundle . to support multiple selections a user must modify presentation views because each collaborator has a selection . when the active collaborator &# 39 ; s selection changes the standard change notification is sent . when a passive collaborator &# 39 ; s selection changes a different notification event is sent . a view should register for both events . since the action taken to respond to either event is usually the same , economy can be realized by registering the same handler method for both events . this portion of the invention is primarily focused on innovative aspects of the user interface building upon the foundation of the operating system framework previously discussed . the first aspect of the user interface is a mechanism allowing a user to manage interactions with various objects or data referred to as controls . the object with which users interact to manipulate other objects or data is called a control . controls use a command to determine the current state of the object or data . following appropriate interactions with the user , the control updates the command &# 39 ; s parameters and causes it to be executed . example controls are menus , buttons , check boxes and radio buttons . controls use a command to determine the current state of the object or data . following appropriate interactions with the user , the control updates the command &# 39 ; s parameters and causes it to be executed . for example , a checkbox sets a command parameter to on or off and then executes the command to change a data value . many controls display the current value of the data they manipulate . for example , a check box displays a check only when a boolean data value is true . as the data changes , the control &# 39 ; s appearance is kept up to date using a notification system described here . the process is similar to the process used to enable / disable menu items . when a control is created a command must be specified . the control makes a copy of this command and stores it in field fcommand . if the command supplies any data values , a pointer to appropriate get and set methods of the command must also be specified . the control stores these method pointers in fields fgetmethod and fsetmethod , respectively . then , the control connects for notifications that indicate its data value may be out of date . each command provides a method called connectdata for this purpose . each control contains a connection object called fdataconnection indicating the object and method to receive the notification . this connection object passed as an argument to the command . the command object calls the connection object &# 39 ; s connect method to add each notifier and interest that may affect its data value . when complete , the control calls the connection object &# 39 ; s connect method to establish the connections as shown in fig3 . the control updates its data value from its command . it does this by calling the get method of the command ( fcommand →( * fgetmethod )()). the control stores this value in an appropriate field ( e . g . a checkbox stores it in a boolean field named fchecked ) as depicted in fig5 . then , the control updates its appearance . it performs this action by calling the view system &# 39 ; s invalidate method , indicating which portion of the screen needs updating . finally , the data changes and notification is sent . at some point , a command is executed which changes the value of the data being reflected by the control . this command could be executed from a control , menu item , or through direct manipulation . the control receives the notification as shown in fig4 and control is passed to await the next user selection . one collection of controls is called a control panel . the controls in a control panel typically operate upon actual data ( this is the default , not a requirement ). their actions are usually immediate and are independent from one another . control panels manage the progression of the input focus among its controls as necessary . it is likely that control panels will be shared across all user interfaces in the system . another collection of controls is called a dialog box . the controls in a dialog box typically operate upon prototypical data ( this is the default , not a requirement ). their actions are usually collected together into a group and then performed together when the user presses an apply button . dialog boxes manage the progression of the input focus among its controls as necessary . we would now like to present a play in three acts to illustrate a control in action . fig2 illustrates the various controls . a play example will be used by way of analogy to illustrate a control ( in this case a checkbox ), a command , a selection , and a data encapsulator . checkbox 200 the role of the checkbox is to display a boolean value stored in the data encapsulator and to facilitate its change . the value is represented by the presence or absence of a check . command 210 the role of the command is to obtain the value from the data encapsulator and change it upon direction from the checkbox . selection 220 the role of the selection is to be an interface between the command and the data . everyone gets to know each other a little better as shown in fig3 . the command 310 tells the checkbox 300 which notifications the data may send in which the control is certain to be interested ( how the command 310 knows is none of anyone else &# 39 ; s business ). the checkbox 300 , in turn , connects to the data 320 for the notifications . unknown to anyone else , the director told the checkbox 300 the best way to interact with the command 310 . specifically , it was told about the command &# 39 ; s get value method and a set value method . the checkbox will take advantage of this a little bit later . something happens to the data -- it sends notifications as depicted in fig4 . the checkbox 400 hears about those for which it has expressed an interest . in fig4 the notification from the data expresses to bold the information which is reflected by placing an x in the checkbox . the checkbox 510 received notification from the data , and the processing to display the checkbox 510 correctly is depicted in fig5 . it does this by using the command &# 39 ; s 520 get value method it happens to know about . before telling the checkbox 510 what the correct value is , the command 520 goes through the selection to the data to make sure it really knows the correct value . the checkbox 510 updates itself as necessary . the user now enters the scene and gives the checkbox 600 a nudge as shown in fig6 . the checkbox 600 uses the command &# 39 ; s 610 set value method to set the data &# 39 ; s 620 value through the selection . the entire process is reviewed in fig7 . a control panel is nothing more than a simple window that contains a set of controls as shown in fig8 . these controls contain a command that operates upon the current selection . the control is enabled if the command is active . following appropriate interaction with the user , the control executes the command , causing the data to change . as an example control panel , consider the sound controller illustrated in fig8 . this control panel contains four buttons 800 , 802 , 804 and 806 for controlling sound playback . each button performs as described in the &# 34 ; a control in action &# 34 ; section above . play 800 this control contains a tplay command . this command is active only under certain conditions , making the control enabled only under those conditions . first , a sound must be selected in the appropriate data encapsulator . next , it must not be playing already . finally , the current sound position must be somewhere before the end . when pressed , the play button executes the tplay command , causing the selected sound to come out of the speaker . step 802 this control contains a tplay command , too . how is this , you ask ? well , since i am making this up , we can pretend that the tplay command takes a parameter indicating the duration it is to play . for the purposes of the step button , it is set to a single sample . the step button is enabled only under the same conditions as described for the play button . when pressed , the step button executes the tplay command , causing the selected sound to come out of the speaker . stop 804 this control contains a tstop command . the stop button is enabled only if the selected sound is currently playing . when pressed , the stop button executes the tstop command , causing the selected sound to stop playing and to set the current sound position to the beginning . pause 806 this control contains a tstop command , too . unlike the stop button , however , this tstop command is set to not rewind the sound to the beginning . pressing the play or step buttons continue from where the playback left off . a dialog box is similar to a control panel , in that it is a simple window containing a set of controls . however , instead of the controls operating upon the selected data , they operate upon parameters of another command . only until the apply button is pressed is the real data modified . as an example dialog box , consider the color editor set forth in fig9 . it contains three sliders , one for the red 900 , blue 910 , and green 920 components of the color . after adjusting the sliders to the desired values , the user presses apply 930 to change the color of the selection . red 900 , green 910 , blue 920 to the user , these sliders are identical , except for their label . as with all controls , each slider contains a command that is executed following user interaction . unlike many controls , especially those in a control panel that immediately affect the selected data , the command contained by these sliders displays and modifies the value of a parameter of another command . in this case , it is one of the red , green , or blue parameters of the command contained within the apply button . apply 930 the apply button contains a tsetcolor command that changes the color of the selection when executed . it has three parameters , one for each of the red , green , and blue components of the color . these parameters are displayed and set by the sliders in response to user interaction . when the apply button is pressed , this command is executed and the new color is set . the internal actions accompanying the color editor example , are depicted in fig1 . the red 1000 , green 1010 , and blue 1020 slides contain a tfloatcontrolcommand . these commands contain a single floating point value which the control displays . as the user adjusts the slider , it updates this value and executes the command . the selection for the tfloatcontrolcommand specifies the tsetcolor command within the apply 1040 button . one of its parameters is set when each tfioatcontrolcommand is executed . finally , when the user presses the apply 1040 button , the tsetcolor command is executed and the selected color 1050 is changed . the following section describes the classes of the controls and dialog areas and their primary methods . a control is the user interface to one or more commands . the control displays information about a command , such as its name and whether it is active in the current context . following appropriate user interaction , the control causes a command to be executed . when appropriate , the control obtains the current value of data the command modifies and displays it to the user . it may set a command parameter that indicates a new value of this data before executing the command . methods to create a selection on the control , with additional specification of a command within the control as an option . lookup command is a pure virtual function in order to give subclasses flexibility in how many commands they contain and how they are stored . methods that are called when the presentation is opened and closed . when the presentation is opened the control connects for notifications that may affect its state . when the presentation is closed these connections are broken . methods that are called when the presentation is activated and deactivated . when the presentation is activated , some controls connect for notifications that are valid only when active . deactivating the presentation breaks these connections . methods that control uses to connect to and disconnect from notifiers that affect whether the control is enabled . connectenablednotifiers connects to the notifiers specified by commands when the control is opened . disconnectenablednotifiers breaks these connections when the control is closed . methods that receive notifications indicating that something happened affecting the control &# 39 ; s presentation of a data value . this method does nothing by default . methods for notification . create interest creates an interest specialized by the control instance . notify is overloaded to send a notification and swallow the interest . a single notifier is shared among many subclasses of controls . in order to express interest in a particular control instance , the interest must be specialized . a control interest is an interest that contains a pointer to a specific control . this class is an internal class that is usually used as is , without subclassing . a single notifier is shared among many subclasses of controls . in order to distinguish which control sent the notification , the notification must be specialized . a control notification is a notification containing a pointer to the control that sent the notification . this class is usually used as - is , without subclassing . a control presenter wraps up a control so it can be contained by a presentation data encapsulator . it implements standard behaviors that all presenter objects implement . this class is usually used as - is , without subclassing . methods that are called when the presentation is opened and closed . they do nothing by default . a subclass must implement these methods for the object it wraps . for controls , these methods are delegated directly to the control . when the presentation is opened , the control connects for notifications that may affect its state . when closed , the connections are broken . methods that are called when the presentation is activated and deactivated . they do nothing by default . a subclass must implement these methods for the object it wraps . for controls , these methods are delegated directly to the control . when the presentation is activated , some controls connect for notifications that are valid only when active . when deactivated , the connections are broken . a control selection specifies a single control , and optionally a command within it , that is wrapped in a control presenter and stored in a presentation . methods to access a command within the control . these may return an invalid value if no command was specified . a unicontrol is the abstract base class for controls that present a single command and causes it to be executed following appropriate user interaction . examples of this type of control are buttons and checkboxes . methods to specify the command that is presented and executed by the control . notification is sent to registered connections when the command is changed . methods the control uses to connect to and disconnect from notifiers that affect whether the control is enabled . connectenablednotifiers connects to the notifiers specified by commands when the control is opened . disconnectenablednotifiers breaks these connections when the control is closed . method that receives notifications indicating that something happened affecting whether the control should be enabled . updateenabled checks whether the command is active and calls enable and disable as appropriate . methods that control uses to connect to and disconnect from notifiers that affect the control &# 39 ; s presentation of a data value . connectdatanotifiers connects to the notifiers specified by commands when the control is opened . disconnectdatanotifiers breaks these connections when the control is closed . controls that do not display a data value ( e . g . button ) may override connect data notifiers to do nothing . a button is a unicontrol that executes its command when pressed . this class is normally used without subclassing ; just set the command and away you go . methods that are called when the presentation is activated and deactivated . when the presentation is activated , some controls connect for notifications that are valid only when active . when deactivated , these connections are broken . when the presentation is activated , buttons register for key equivalent notification . this connection is broken when the presentation is deactivated . methods that control users connecting to and disconnecting from notifiers that affect the control &# 39 ; s presentation of a data value . connect data notifiers connects to the notifiers specified by commands when the control is opened . disconnect data notifiers breaks these connections when the control is closed . controls that do not display a data value ( e . g . button ) may override connect data notifiers to do nothing . a checkbox is the user interface to a command that sets a boolean value . following appropriate user interaction , the checkbox calls a command method to change the value and executes the command . this class is normally used without subclassing ; just set the command , its value getter and setter , and away you go . a slider is a unicontrol that displays a single floating point value and allows it to be changed following appropriate user interaction . examples of sliders were presented in fig9 and 10 . a multicontrol is the abstract base class for controls that present several commands and causes them to be executed following appropriate user interaction . examples of this type of control are radio buttons and menus . a radio button is a multicontrol that displays two or more boolean values and allows them to be changed following appropriate user interaction . the radio button enforces the constraint that exactly one button is selected as shown in fig1 . if paper is selected , then the circle at 1100 is blackened . if plastic is selected , then the circle at 1110 is selected . both cannot be selected . a command encapsulates a request to an object or set of objects to perform a particular action . commands are usually executed in response to an end - user action , such as pressing a button , selecting a menu item , or by direct manipulation . commands are able to provide various pieces of information about themselves ( e . g . name , graphic , key equivalent , whether they are active ) that may be used by a control to determine its appearance . subclasses must implement a method to examine the current selection , active user interface element , or other parameters in order to decide whether the command is active . subclasses must override get active interest list to return notification interests that may affect whether this command is active . fig1 is a flowchart depicting the detailed logic in accordance with the subject invention . the flowchart logic commences at 1200 and control passes directly to function block 1210 where a command objects are added to a menu . the steps carried out by this function block are : 1 ) create menu item from a command , where a menu item is another object data structure containing a command , 2 ) add a menu item to a list of menu items , and 3 ) mark the menu &# 39 ; s appearance is invalid in data structure fvalid . then , later when the menu is pulled down , the appearance is recomputed based on the system state . each menu is a view . views contain size and location information . each menu contains a list of menu items . each menu item contains a command and variables that reflect its current appearance . this includes whether the menu item is enabled ( boolean fenabled ), its name ( ttextlabel fname ), its graphic ( tgraphiclabel fgraphic ), and whether its appearance is currently valid ( boolean fvalid ). each of these variables are determined by asking the command when the menu item was created . next , a query is sent to the command object for notification interests as depicted in function block 1220 . each command has four methods to connect for different types of notifications : i ) notifications that affect it &# 39 ; s name , ii ) notifications that affect a graphic , iii ) notifications that affect whether the command is active , and iv ) notifications that affect any data . in this case , the menu item just created for the command connects for active notification . it does this by passing a connection object to connectactive . the command is then responsible for connecting the connection object to notifiers affecting whether the command is active . then control is passed to function block 1230 to query a command for the enabled state when it is necessary to draw a menu item . to draw a menu item , menu item calls method &# 34 ; isactive &# 34 ; for its command . the command looks at whatever system state it wants to and returns whether it is active as depicted in decision block 1240 in the current context ( e . g . some commands only are active when a particular type of window is in front , or when a particular type of object is selected ). then , a menu item updates its internal state ( a boolean value in each menu item ) and appearance as shown in function block 1250 and 1260 to match the value returned by the command . whenever a user action invokes any command as shown in input block 1270 , a user causes a command to be executed . this could be from a menu item , control , or through direct manipulation of an object . this action causes a document state to be modified as shown in function block 1280 , and a document sends notification as shown in function block 1290 . when a document sends notification , the following steps are executed : 1 ) any menu item ( or other control ) connected for the notification sent by the document receives a notification message . this message includes the name of the change as well as a pointer to the object that sent the notification ) a menu item then updates its state , and control is passed back to function block 1230 for further processing . fig1 is an illustration of a display in accordance with the subject invention . the menu item is edit 1300 and has a number of sub - menu items associated with it . undo 1310 is an active menu item and can thus be selected to carry out the associated functions . redo 1320 is inactive and is thus presented in a greyed out fashion and cannot be selected at this time . a checkbox is also shown at 1360 as part of the debugging control panel 1350 . data presentations are created from templates and saved across sessions in a user interface object . the container for all data in the system is a model . a model contains and facilitates the manipulation of data . data exchange is facilitated through cut , copy , and paste operations . data reference is provided by selections , anchors , and links . data models may be embedded into any other . users interact with models through presentations ( e . g . icon , thumbnail , frame , window , dialog , control panel ) that are provided by an associated user interface . data models delegate all presentation creation and access methods to another object , called the user interface . a user interface is a model containing a set of presentations ( e . g . icon , thumbnail , frame , window ) for a particular model . when required , presentations are selected from those already created based on the type of presentation desired , the user &# 39 ; s name , locale , and other criteria . if the desired presentation is not found , a new presentation is created and added to the user interface by copying one from an associated archive . presentations may be deleted when persistent presentation information ( e . g . window size and location , scroll positions ) is no longer required . a presentation contains a set of presentable objects that wrap user interface elements ( e . g . menus , windows , tools ) used to view and manipulate data . presentations provide a reference to the data these objects present . presentations install or activate presentable objects when the presentation is activated . similarly , these objects are removed or deactivated when the presentation is deactivated . presentations are identified according to their purpose ( e . g . icon , thumbnail , frame , window ) and retain yet - to - be - determined criteria ( e . g . user identity ) for later selection . a presentation is made up of a collection of presentable objects ( e . g . user interface elements ) that are displayed on the screen or are otherwise available when the presentation is open or active . presentations are created from template presentations contained in an archive . these are made up of objects such as user interface elements , which are , in turn , made up of smaller objects such as graphics and text strings . an archive is a model containing a set of template objects , including user interface elements ( e . g . windows , menus , controls , tools ) and presentations ( e . g . icon , thumbnail , frame , window ). by using command objects in different ways , we can control two independent behaviors of a group of controls . the first is whether they affect the data immediately , or whether the user must press ok before the settings take effect . the second is whether they are independent from one another , or whether the settings represent an atomic operation . controls contain commands . as the user manipulates the control , the control sets parameters in the commands and cause it to be executed . commands operate on model data specified by a selection . controls that affect the data immediately contain a command that contains a selection that specifies real model data . as the user manipulates the control , the command causes this data to change . as the data changes , it sends change notification so that views and controls depending on the state of the data can accurately reflect the current state . controls that are designed to not change the real data must operate on prototypical data , instead . the real model data is not changed until the user performs another action , such as pressing the ok button . this is accomplished in two ways : the control contains a command that contains a selection that specifies the control itself . as the user manipulates the control , the command causes the control &# 39 ; s value to change , but no other model data . when the user presses ok , a command in the ok button changes the real model data to match the values in each control the user may have manipulated . the control contains a command that contains a selection that specifies a parameter of the command contained by the ok button . as the user manipulates the control , the command causes the ok button &# 39 ; s command to change . when the user presses ok button , the ok button &# 39 ; s command changes the real model data to match the values contained in itself . controls that act independently from one another require represent actions that can be individually undone after the control panel or dialog session is complete . this is the normal behavior of commands once they are executed by controls . other sets of controls are designed to work together and should be undone and redone as an atomic operation . this is accomplished by putting a mark on the undo stack when the dialog box or control is started . when finished , either by dismissing the control panel or when the user presses an ok button ( as in ii b above ), all of the commands executed since the mark was placed on the undo stack are collected together into a single command group . this group can then be undone or redone as a single group . control panels containing a cancel button ( usually accompanied by an ok button , as in ii b above ) us a technique similar to that described iii b above . a mark is put on the undo stack when the dialog box or control panel is started . if the user presses the cancel button , all commands placed on the undo stack since the mark are undone . this technique works regardless of whether the controls affect the data immediately or not . the object with which users interact to manipulate other objects or data is called a control . example controls are menus , buttons , check boxes , and radio buttons . each control contains a command , which implements an end - user action . commands operate on data that is specified by a selection object . as the user manipulates the control it sets parameters in the command and causes it to be executed , thus changing the data value . controls that act independently from one another require represent actions that can be individually undone after the control panel or dialog session is complete . this is the normal behavior of commands once they are executed by controls . other sets of controls are designed to work together and should be undone and redone as an atomic operation . this is the subject of this patent . the detailed logic of the atomic execution is set forth in the flowchart presented in fig1 . processing commences at terminal 1400 where control is immediately passed to function block 1410 where a dialog box is activated . when the dialog box is activated , a mark is placed on the undo stack . the undo stack is a list of all commands the user has executed . when undo is pressed , the command on the top of the stack is undone . if not immediately redone , it is thrown away . then , at function block 1410 , a user manipulation of a control is detected . the manipulation of a control changes the command &# 39 ; s data value , as appropriate as set forth in function block 1430 , and executes the control . for example , a checkbox toggles the command &# 39 ; s fchecked field between 0 and 1 . finally , the command is recorded on the undo stack so it can be subsequently undone as shown in function block 1440 . as a user subsequently manipulates each control in the dialog box , as detected in decision block 1450 , then control passes to function block 1430 . however , if a user presses ok as detected in decision block 1460 , then control passes to function block 1420 . finally , when each control in the dialog box is set to the user &# 39 ; s satisfaction , the user presses the ok button . all of the commands executed since the mark was placed on the undo stack in function block 1440 are collected together into a single command group and placed back onto the undo stack as depicted in function block 1470 . a command group is a command that collects many commands together . when executed , undone , or redone , the command group executes , undoes , or redoes each command in sequence . the command group is then placed back onto the undo stack where it can be undone or redone as a single atomic operation . the object with which users interact to manipulate other objects or data is called a control . example controls are menus , buttons , check boxes , and radio buttons . each control contains a command , which implements an end - user action . commands operate on data that is specified by a selection object . as the user manipulates the control it sets parameters in the command and causes it to be executed , thus changing the data value . delaying changing of data until the user performs another action is one aspect of the subject invention . for example , controls in a dialog box may not want to change any data values until the user presses the ok button . when a control is created a command must be specified . the control makes a copy of this command and stores it in field fcommand . if the command supplies any data values , a pointer to appropriate get and set methods of the command must also be specified . the control stores these method pointers in fields fgetmethod and fsetmethod , respectively . the data that is modified by a command is specified by a selection object . normally , this selection object specifies real model data . instead , a selection object that specifies the data value within the command of the ok button . when a user manipulates the control , the control &# 39 ; s command is executed and a data value within the command of the ok button is changed . as the user manipulates each control in the dialog box , the control &# 39 ; s command is executed and a data value within the command of the ok button is changed . thus , when a user presses the ok button , the command in the ok button updates the real model data to match the data values contained within itself as manipulated by the control &# 39 ; s commands . this processing is repeated until control processing is completed . labels are graphical objects that contain a graphic or text string . they are used to identify windows , menus , buttons , and other controls . labels are able to alter their appearance according to the state of their container . they are drawn on a medium - gray background and appear naturally only when no special state must be indicated . labels modify their appearance when inactive , disabled , or selected . window titles are set to be inactive when the window is not front - most . similarly , control labels are set to be inactive when the control is not in the front - most window or other container . graphic labels are blended with 55 % white when inactive , in order to appear dimmed . for text labels , the inactive paint is derived from the natural paint by manipulating the saturation component of the hsv color model . the saturation is multiplied by 0 . 45 when inactive . control labels are dimmed when the control does not apply in a particular context . graphic labels are blended with 46 % white when inactive , in order to appear dimmed . for text labels , the disabled paint is derived from the natural paint by manipulating the saturation component of the hsv color model . the saturation is multiplied by 0 . 54 when disabled . control labels are highlighted as the control is being manipulated . graphics and text are drawn in their natural state , but on a white background , when highlighted . controls use a command to determine the current state of the object or data . following appropriate interactions with the user , the control updates the command &# 39 ; s parameters and causes it to be executed . for example , a checkbox sets a command parameter to on or off and then executes the command to change a data value . controls display a label to indicate its function . this label is a graphical object containing a graphic or a text string . as the control changes state , the label automatically adjusts its appearance , without requiring the developer to write additional code . these states include active / inactive , enabled / disabled , and selected / unselected . fig1 sets forth the detailed logic associated with smart label processing which commences at the start terminal 1500 where control is immediately passed to 1510 for smart label initialization . when the control is created , its label is initialized with a text string or graphic provided by its associated command . each command provides methods called getgraphic and getname for this purpose . the control tells the label whether it is currently active or inactive by calling method setactive . similarly , the control calls method setenabled to tell the label whether it is enabled , and setselected to tell the label whether it is currently being selected by a user . the next step in smart label processing occurs at function block 1520 when the label is drawn . when the control is activated , it calls the draw method of its label , causing the label to appear on the screen . if inactive , the label is drawn more dimly than normal . this is done by manipulating the saturation components of the hsv color model . the saturation is multiplied by 0 . 45 when inactive . if disabled , the label is drawn more dimly than normal . this is done by manipulating the saturation components of the hsv color model . the saturation is multiplied by 0 . 54 when the label is disabled . if selected , the label on a highlighted background . labels are normally drawn on a medium - gray background . when highlighted , labels are drawn on a white background . otherwise , the label is drawn normally . the next processing occurs when a label is activated / deactivated as shown in function block 1530 . when the control is activated or deactivated , it tells the label by calling the setactive method . the control then indicates its appearance needs updating by calling invalidate with an argument indicating the portion of the screen that needs to be redrawn . then , at function block 1540 , processing occurs when a control is enabled / disabled . when the control is enabled or disabled , it tells the label by calling the setenabled method . the control then indicates its appearance needs updating by calling invalidate with an argument indicating the portion of the screen that needs to be redrawn . a test is then performed at decision block 1550 to determine if a control is selected or unselected . when the control is selected or unselected , it tells the label by calling the setselected method . the control then indicates its appearance needs updating by calling invalidate with an argument indicating the portion of the screen that needs to be redrawn , and control is passed to function block 1520 for further processing . a title is displayed in a window in order to indicate its purpose . for example , the title for a window to edit a document is usually the name of the document . a label object is used to keep track of the title . this label is a graphical object containing a graphic or a text string . as the window changes state , the label automatically adjusts its appearance , without requiring the developer to write additional code . windows can be either active or inactive . smart window label processing is flowcharted in fig1 and the detailed logic is explained with reference thereto . processing commences in fig1 at terminal 1600 where control is immediately passed to function block 1610 for the title to be initialized . a window title is specified by a developer when a window is created . this title is stored in a tlabel object called ftitle . the control tells the title whether it is currently active or inactive by calling method setactive . then , the at function block 1620 . when a window is drawn , it calls the draw method of its ftitle object , causing the title to appear on the screen . if inactive , the title is drawn dimmer than normal . this is done by manipulating the saturation components of the hsv color model . the saturation is multiplied by 0 . 45 when inactive . otherwise , the title is drawn normally . the next step is processed at function block 1630 when the title is activated / deactivated . when a window is activated or deactivated , it tells its ftitle object by calling the setactive method . the window then indicates its appearance needs updating by calling invalidate with an argument indicating the portion of the screen that needs to be redrawn . then , control is passed back to function block 1620 for redrawing the title to reflect its new state . many of the visual aspects of user interface elements are common among many elements . examples are shadows , borders , and labels . the individual visual features are referred to as decorations . decorations can be combined with other graphics to form the visual appearance of specific user interface elements , such as windows and controls . the subject invention supports many different types of decorations . a decoration that is drawn behind another object is called a background . one type of background is drawn so as to appear flush with the surrounding drawing surface . it may be drawn with or without a frame . another type of background is drawn with highlighting and shadow so it appears to be raised above the surrounding drawing surface . the final type of background is drawn with highlighting and shadow so it appears to be recessed beneath the surrounding drawing surface . an example use of these backgrounds is a button . normally the text or graphic that describes the button is drawn on a raised background . when pressed by the user , the text or graphic is redrawn on a recessed background . if the button is inactive , such as when another window is active , the text or graphic of the button could be drawn dimly on a flush background . a decoration that surrounds another object or area is called a border . example borders are frames and shadows . a frame is a border that surrounds another graphic , much like a frame encloses a painting in the real world . like backgrounds , frames can be drawn to appear recessed below , flush with , or raised above a surrounding drawing surface . a shadow is a special type of border that adds a shadow around an object to make it appear as if it floats above the surrounding surface . many of the visual aspects of user interface elements are common among many elements . examples are shadows , borders , and labels . each of these individual visual features are referred to as a decoration . decorations can be combined with other graphics to form the visual appearance of specific user interface elements , such as windows and controls . some decorations use highlighting and shadows to appear as if they are above or below the surrounding drawing surface . decorations are able to derive automatically these highlighting and shadow paints . the fill paint represents the decoration &# 39 ; s primary color . all other paints are derived from the fill paint . the fill paint is stored by the directoration in a tcolor field called ffillpaint . the fill paint is normally specified by the developer when the decoration is created . however , if no color is specified , a medium gray is selected . the frame paint is used to draw a line around the decoration to provide visual contrast . the frame paint is stored by the decoration in a tcolor field called fframepaint . the frame paint may be specified by the developer when the decoration is created . however , if no frame paint is specified , it is computed automatically from the fill paint . this is accomplished by manipulating the saturation and value components of the hsv color model . the saturation is multiplied by four , with a maximum value of 1 . the value is divided by four . the highlight paint is used to draw lines where light would hit the object if it were an actual three - dimensional object . the highlight paint is stored by the decoration in a tcolor field called fhighlightpaint . the highlight paint may be specified by the developer when the decoration is created . however , if no highlight paint is specified , it is computed automatically from the fill paint . this is accomplished by manipulating the saturation and value components of the hsv color model . the saturation is multiplied by 0 . 8 . the value is multiplied by 1 . 25 , with a maximum value of 1 . the shadow paint can be used to draw lines where the object would be shaded if it were an actual three - dimensional object . the shadow paint is stored by the decoration in a tcolor field called fshadowpaint . the shadow paint may be specified by the developer when the decoration is created . however , if no shadow paint is specified , it is computed automatically from the fill paint . this is accomplished by manipulating the saturation and value components of the hsv color model . the saturation is multiplied by 2 with a maximum value of 1 . the value is divided by 2 . a graphical user interface is manipulated by moving a mouse , clicking on objects to select them , dragging objects to move or copy then , and double - clicking to open them . these operations are called direct manipulations , or interactions . the sequence of events corresponding to a user pressing , moving , and releasing a mouse is called an input syntax . certain sequences of events are used to indicate particular actions , called semantic operations . the separation of the code that understands the input syntax from the code that implements semantic operations is the subject of this patent . this processing is embodied in objects called interacts and intractable , respectively . fig1 illustrates how these objects are created and how the objects communicate with each other during a typical interaction with an object that can be moved and selected . processing commences at terminal 1700 where control is passed immediately to function block 1710 to determine if the mouse button has been pressed . an event is sent to the object responsible for the portion of the screen at the location where the mouse button was pressed . this object is called a view . then , at function block 1720 the interactor is created to parse the input syntax . this is done by calling the createinteractor method of the view . when the interactor is created , pointers to objects that implement possible user actions are passed as parameters . for the purposes of this discussion , assume the user pressed the mouse button down on an object that can be selected and moved . in this case , an object that implements selection and an object that implements movement for the target object are passed as parameters to the interactor . the initial view could implement both of these behaviors , or they could be implemented by one or two separate objects . the object or objects are referred to collectively as the interactable . the interactor is started at function block 1730 . this processing returns the interactor to the view and commences processing of the interactor . this is accomplished by calling the interactor &# 39 ; s start method and passing the initial mouse event as a parameter . the start method saves the initial mouse event in field finitialevent . since only one mouse event has been processed thus far , the only action possible is selecting . the interactor enters select mode by setting variable finteractiontype to constant kselect . it asks the interactable to begin the selection operation by calling its selectbegin method . then , the interactor waits for a short time to pass as shown in function block 1740 . a new mouse event is sent to the interactor when the time is up which indicates the current state of the mouse . then , if the system detects that the mouse is still down at decision block 1750 , control is passed to function block 1740 . otherwise , control is passed to terminal 1760 . if the mouse button is still down , the interactor makes sure it is still in the correct state and asks the interactable to implement the correct operation . the interactor is selecting if finteractiontype is kselecting . it is moving if the finteractiontype is kmoving . if selecting , the interactor compares the current mouse location with the initial mouse location . the current mouse location is obtained by calling the getcurrentlocation method . the initial mouse location is obtained by calling the getinitiallocation method . if the two are the same or differ by only a small amount , the user is still selecting the object . the interactor then asks the interactable to continue the selection operation by calling its selectrepeat method . however , if the two points differ beyond a predetermined threshold , the user has begun moving the object . in this case , the interactor asks the interactable to terminate the selection operation by calling its selectend method . it then asks the interactable to begin the move operation by callings its movebegin method . in each case , the current mouse location is passed as an argument . if moving , the interactor asks the interactable to continue the move operation by calling its moverepeat method . it passes the current mouse location as an argument . when the user releases the mouse button , it signals the end of the current operation . if selecting , the interactor asks the interactable to terminate the selection operation by calling its selectend method . if moving , the interactors asks the interactable to terminate the move operation by calling its moveend method . localization is the process of updating an application to conform to unique requirements of a specific locale . it may involve language translation , graphic substitution , and interface element reorientation . for example , the text used in labels , titles , and messages depends upon the selected language . its direction and orientation may affect the placement and orientation of a menu , menubar , title , scrollbar , or toolbar . similarly , the selection of icons and other graphical symbols may be culturally dependent . unfortunately , having many localized versions of user interface elements in memory is very expensive . instead , localized versions of user interface elements are kept on disk until required in memory . further , it is very error - prone and expensive to keep track of all of the user interface elements and decide which version to use . instead , when a user interface element is required , the appropriate one is selected automatically by the system , according to the current language and other cultural parameters , and read into memory . once localized , user interface elements are stored in a disk dictionary . a disk dictionary is an object that , when given a key , returns a value after reading it in from disk . this disk dictionary is managed by an object called an archive . an archive is responsible for putting together the individual user interface elements that make up a particular presentation . the process of selecting the proper user interface element is presented in fig1 . processing commences at terminal 1900 and immediately passes to function block 1910 when a user requests a presentation . a topenpresentation command is sent to the data model , indicating that the user wants to view or edit this data . a command is sent to the data model to indicate that the user wants to view or edit the data . this command is called a topenpresentationcommand . a presentation is a set of user interface elements that , together , allow the user to view or edit some data . presentations are stored across sessions in user interface object , thus maintaining continuity for the user . user interface elements are stored on disk until needed in memory . they may be required as part of a data presentation the user has requested , or they may be needed for translation or another localization process . each user interface element contains an id which uniquely references that element . however , all localized versions of the same user interface element share a single id . in order to differentiate the localized versions , the particular language , writing direction , and other cultural parameters are stored with each localized user interface element . together , these parameters are referred to as the locale . all of the user interface elements are stored in a file . this file is organized like a dictionary , with one or more key / value pairs . the key is an object which combines the id and the locale . the value is the user interface element itself . a new presentation must be created next at function block 1920 . if an appropriate presentation does not already exist , a new one must be created from a template by the user interface archive . a new presentation is created from a template stored in the archive by calling its createpresentation method . a presentation type is passed to this method as a parameter . this type includes such information as the type of data to be displayed , whether it is to be in its own window or part of another presentation , and so on . finally , at function block 1930 , an archive builds the presentation , selecting user interface elements according to locale . if the archive is able to build a presentation of the specified type , it collects together each user interface element that makes up the presentation and returns this to the user interface object . for each presentation the archive is able to make , it has a list of user interface element ids that together make up the presentation . the user interface elements are stored on disk maintained by a disk dictionary object called . given a key , the disk dictionary will return the corresponding user interface element . the user interface element id makes up the primary component of this key . a secondary component of the key is the desired locale . a locale is an object that specifies the natural language and other cultural attributes of the user . the locale obtained automatically by the archive from a preferences server . this server contains all of the individual preferences associated with the user . the locale , as obtained from the preferences server , is combined with the id into a single object called a tuserinterfaceelementkey . this key passed as a parameter to the getvalue method of the disk dictionary . if a user interface element with a matching id and locale is found , it is returned and included as part of the presentation . otherwise , the locale parameter must be omitted from the key , or another locale must be specified until an appropriate user interface element is found . users of an object oriented operating system &# 39 ; s graphical user interface often move a mouse , click on objects to select them , drag objects to move or copy then , and double - click to open an object . these operations are called direct manipulations , or interactions . the sequence of events corresponding to a user pressing , moving , and releasing the mouse is called the input syntax . certain sequences of events are used to indicate particular actions , called semantic operations . this invention discloses the method and apparatus for translating input syntax into semantic operations for an object that supports select , peek , move , autoscroll , and drag / drop ( copy ). the invention detects a mouse button depression and then employs the following logic : ( a ) if an option key was depressed when the user pressed the mouse button , the system enters drag mode by setting variable finteractiontype to constant kdrag . the system then commences a drag operation using the selected object as the target of the operation ; or ( b ) if the option key was not depressed , then the system enters selection mode by setting variable finteractiontype to constant kselect . then , the select operation is commenced . if a user already had the mouse button depresses and continues to hold the mouse button down , then the following logic is engaged . if the system is in select mode , then the system first determines whether the user has moved the mouse beyond a certain threshold , called the move threshold . this is done by comparing the initial mouse location , returned by the getinitiallocation method , with the current mouse location , returned by the getcurrentlocation method . if the mouse has moved beyond the move threshold , the system ends select mode and enters move mode . it does this by setting variable finteractiontype to constant kmove . the system then queries the object to terminate the select operation by calling its selectend method . the system then initiates a move operation by calling its movebegin method . otherwise , if the mouse has not moved , the system checks how long the mouse has been down . it does this by comparing the initial mouse down time , returned by the getinitialtime method , with the current time , returned by the getcurrenttime method . if the mouse has been down beyond a certain threshold , called the peek threshold , the system ends select mode and enters peek mode . it does this by setting variable finteractiontype to constant kpeek . it asks the object to end the select operation by callings its selectend method , and begins a peek operation by calling its peekbegin method . otherwise , if the mouse has not moved , or it has not been down beyond the peek threshold , the system continues the select operation by calling the object &# 39 ; s selectrepeat method . if the system detects that a user is in move mode , the system first determines whether the user has moved the mouse within the window , on the border of the window , or outside the window . it does this by comparing the current mouse location , returned by the getcurrentlocationmethod , with the bounds of the object &# 39 ; s container , returned by getcontainerbounds . if the mouse is still within the bounds of the window , the system continues the move operation by calling the object &# 39 ; s moverepeat method . if the mouse is on the border of the window , this indicates an autoscroll operation . the system asks the object &# 39 ; s container to scroll in the direction indicated by the mouse location . this is done by calling the container &# 39 ; s autoscroll method and passing the current mouse location as a parameter . once complete , the system continues the move operation by calling the object &# 39 ; s moverepeat method . if the mouse has moved outside the window , the system ends move mode and enters drag mode . it does this by setting variable finteractiontype to constant kdrag . it asks the object to end the move operation by calling its moveend method . it asks the object to begin the drag operation by calling its dragbegin method . if the system is in drag mode , the system continues the drag operation by calling the object &# 39 ; s dragrepeat method . if the system is in peek mode , the system first determines whether the user has moved the mouse beyond a certain threshold , called the move threshold . this is done by comparing the initial mouse location , returned by the getinitiallocation method , with the current mouse location , returned by the getcurrentlocation method . if the mouse has moved beyond the move threshold , the system ends peek mode and enters move mode . it does this by setting variable finteractiontype to constant kmove . it asks the object to end the peek operation by calling its peekend method . it asks the object to begin the move operation by calling its movebegin method . otherwise , if the mouse has not moved , the system continues the peek operation by calling the object &# 39 ; s peekrepeat method . if the system detects that a user releases the mouse button , then if the system is in select mode , the system ends select mode . it does this by setting variable finteractiontype to constant knone . the system queries the object to end the select operation by calling its selectend method . if the system is in move mode , the system ends move mode . it does this by setting variable finteractiontype to constant knone . then , the system queries the object to end the move operation by calling its moveend method and ends drag mode by setting variable finteractiontype to constant knone . it asks the object to end the drag operation by calling its dragend method . if the system is in peek mode , the system ends peek mode . it does this by setting variable finteractiontype to constant knone . it asks the object to end the peek operation by calling its peekend method . accordingly , it is a primary objective of the present invention to provide an innovative hardware and software system which enables the contents of a window to update dynamically as a user moves a scrollbar thumb . the system detects when a user presses down on a scrollbar thumb . when the user presses down on the scrollbar thumb , the system begins initiation of a scroll command to change the portion of the data that is exposed in the window . a command is an object that implements an end - user action , such as scrolling . a scroll command has one parameter , the position to which the content view should be scrolled . the system sets this position to the current scroll position . this is accomplished by calling the command &# 39 ; s setscrollposition and setting the scroll to position to the value returned by the scrollbar &# 39 ; s method getscrollposition . when a user moves the mouse within the scrollbar , the system continues the execution of the scroll command to dynamically change the portion of the data exposed in the window . the system sets the scroll position of the command to the new scroll position . this is accomplished by calling the command &# 39 ; s setscrollposition and setting the value equal to the value returned by the scrollbar &# 39 ; s method getscrollposition . the execution of the command is then repeated by calling its dorepeat method . this causes the content view to scroll to the new position . this processing is continued while a user continues to hold the mouse button down . when a user releases the mouse button , the system ends the execution of the scroll command to dynamically change the portion of the data exposed in the window . the system sets the scroll position of the command to the final scroll position . this processing is accomplished by calling the command &# 39 ; s setscrollposition and setting it equal to the value returned by the scrollbar &# 39 ; s method getscroll position . fig2 is a flowchart illustrating the detailed logic associated with scrolling in accordance with the subject invention . processing commences at terminal block 2000 and immediately passes to function block 2010 where the current scroll position is initialized based on the current cursor location . then , at decision block 2020 , a test is performed to detect if the scrollbar thumb has been selected . an example of a scrollbar thumb is shown in fig2 a at label 2110 . if the scrollbar thumb has been selected , then control passes to decision block 2030 to determine if the scrollbar thumb has been moved . if so , then the scroll position is set to the new position of the scrollbar thumb and the display is reformatted to reflect the immediate scroll operation and displayed for the user . if the scrollbar thumb has not moved , another test is performed at decision block 2050 to determine if the scrollbar thumb has been released . if not , then control is returned to decision block 2030 . if the scrollbar thumb has been released , then control passes to function block 2060 to end the scroll operation and return the system to a non - scroll operational status and processing is completed at terminal 2070 . fig2 a , 21b and 21c illustrate window scrolling in accordance with the subject invention . in fig2 a , the scrollbar thumb 2110 is located at the top of the window 2112 . fig2 b shows the scrollbar thumb 2120 moved to the middle of the window and the window &# 39 ; s contents 2122 updated accordingly . fig2 c shows the scrollbar thumb 2140 moved to the bottom of the window and the bottom most portion of the window 2142 displayed . collaboration commences by starting the model server by invocation of a process . for example , a user double - clicking on a document on the display invokes the task initiation portion of the operating system . this invocation creates a task . the task is created by a ttaskprogram object encapsulating information required to create the new task . fig2 illustrates the class hierarchy for task management in accordance with the subject invention . the detailed design of each of the blocks shown in fig2 is presented below . fig2 illustrates the process for creating a main task on another team by tteamhandle . ttaskprogram objects use the interface on tteamhandle to create a new team . suppose we want a new team to execute the &# 34 ; runtest - t maintimemediatest - i timemediatest &# 34 ; command line . we pass this text into the constructor for tcommandline . the tteamhandle constructor flattens the tcommandline and streams it to the nubserver task on the target team . on the target team , the nubserver resurrects the tcommandline , and uses the abstract interface defined by the ttaskprogram class to prepare the &# 34 ; runtest &# 34 ; program to execute . the initialize method locates the &# 34 ; runtest &# 34 ; executable library , loads that library and those that it requires , and obtains the address of &# 34 ; main .&# 34 ; the run method calls &# 34 ; main .&# 34 ; the flow of control is partitioned into two separate methods , initialize and run . the initialize method performs any work to prepare the user code for execution . in the case of the tcommandline subclass , this involves all the steps up to and including loading the required libraries and finding the address of the &# 34 ; main &# 34 ; entry point . when the initialize method returns , the task that called the tteamhandle constructor is unblocked . in other words , the constructor on the creating team is synchronous with the initialize method in the new task on the target team . the creating task is given a confirmation that its action succeeded , to the point of entering the &# 34 ; user code ,&# 34 ; such as a &# 34 ; main ( argc , argv )&# 34 ; entry point . the creating task may safely assume , for instance , that libraries have loaded , that it may jump to entry point addresses , that static data has been initialized , and that it may send messages . second , defining separate initialize and run methods provides an exception model that distinguishes between ttaskprogram exceptions and client code exceptions . for example , if an exception occurs in the initialize method , we cause an exception to occur in the constructor , which signals the creating team that its action failed . this might occur if the initialize method fails to locate , load , or initialize some set of required libraries . if an exception occurs in the run method , then this event reflects an unhandled exception in the client code . an exception occurring during the run method may additionally notify or log , as required . sometimes specific subclasses of ttaskprogram may have clients that require synchronization beyond the simple &# 34 ; block until initialize returns &# 34 ; model . suppose that the creator of a task needs to synchronize with the target task after the target task attains some known state . a simple protocol is described here . the creator passes in an exchange into the ttaskprogram on which it , or some other entity , will later perform a receive . after the target task has attained some pre - arranged state , it performs a send to the exchange it was given . the reply unblocks the target task , who knows that the creating task ( or other entity that knows the exchange ) has acknowledged the task &# 39 ; s attainment of the pre - arranged state . fig2 is a flowchart of the detailed logic in accordance with the subject invention . processing commences at terminal 2400 which immediately passes control to function block 2410 where a user has double clicked on a document object . then , at function block 2420 , the task program creates a new address space and inserts an object into the address space , and causes a task to be created in the address space and begin a method of the object . that object opens a document file and resurrects a document object and calls a start method for the object as shown in function block 2430 . the method first checks to see if a model server is active for the document . then , if no model server is active , the method creates and initiates a model server as shown in function block 2440 , reads in the document and opens the user interface associated with the document as shown in function block 2450 . the user can then enter commands . if there is a model server , then the method connects to the existing model server , retrieves a copy of the document from the model server , opens the user interface , and the user can then enter commands . there are two basic types of commands , a non - repeating command and a repeating command . non - repeating commands perform their actions as a single atomic operation . repeating commands have a beginning phase , zero or more continuing phases and an end phase . for some commands , some of the continue phases can be skipped without affecting the result of the command . for the non - repeating command , the tracker , which is invoked when a user takes any action , examines the user action as depicted in function block 2460 , determines what command the user intends to issue , and executes the do method of the command . for example , if a user double - clicks on an icon , the open command is issued for the icon that was double - clicked . the do method of the command transmits the command to the model command dispatcher . the model command dispatcher ( mcd ) receives commands and distributes commands to the model server as depicted in function block 2470 . the model server is an object responsible for maintaining the list of collaborators , deciding which collaborator has the authority to change the model , and distributes commands to all active collaborators as shown in function block 2480 . when the model server receives a command , it determines if the collaborator sending the command is permitted to issue a command . if not , then an error is returned . if the command is permitted , then the command is sent to each of the other active collaborator &# 39 ; s model command executive , and the command is returned to the sending collaborator &# 39 ; s model command dispatcher . the model command dispatcher stores the return command back into the original command , and then executes the handle do method of the command . this method modifies the model based on the command . the model generates notification which is distributed by the notification framework to any interested views . the views receive the notification , examine the notification and the model to present a current view of the model . for example , if a command of double - clicking on an object turned the selected object red , then the view would redraw the object as a red object when it was double - clicked on . then a graphic view would redraw the object as a color red object . whereas , a text only display would place a label red under the object . after notification is generated , control returns to the dispatcher which returns control to the tracker . when a collaborator &# 39 ; s model command executive receives a command from the model server , it calls the handle do method of the command . this method modifies the model based on the command . the model generates notification which is distributed by the notification framework to any interested views . the views receive the notification , examine the notification and the model to present a current view of the model . for example , if a command of double - clicking on an object turned the selected object red , then the view would redraw the object as a red object when it was double - clicked on . then , a graphic view would redraw the object as a color red object . whereas , a text only display would place a label red under the object . after notification is generated , control returns to the model command executive to await another command . fig2 is a diagram of a typical tracking loop used in prior art systems such as the apple macintosh . this loop allows a user to interact with a computer using the mouse and the screen . simple tracking works well for many kinds of user interaction , but it is difficult to use in the document architecture . the document architecture allows multiple views of the same data to reside on multiple machines . it would be unwieldy to require each tracker to know how to draw feedback into every possible kind of view on every possible collaborator &# 39 ; s machine . abstract trackers were the first attempts used to support tracking in multiple views and across multiple machines . when tracking begins , one abstract tracker and a number of feedbackers are created . one feedbacker is created for each view , on each machine . the abstract tracker converts the concrete , device - based events into abstract , model - based events . the model events are distributed to the various feedbackers , where they are used to provide feedback to the views . fig2 illustrates an example of an abstract tracker loop . abstract trackers allow collaborative and multi - view tracking , but there are problems : the feedbackers usually end up duplicating display code which is already implemented in the views . the feedbacker only pretends to incrementally modify the model . for complex models , such as text editors and constraint - based 3d graphic editors , the feedbacker may not be able to adequately simulate the effect of the user &# 39 ; s input . if the tracker actually modified the model , everything would be much simpler . and , in fact , this is what happens in the model - based tracking loop . the tracker issues commands to the model , which posts change notifications to all interested views as shown in fig2 . the c language code used to implement the tracker is presented below : ______________________________________class tmytracker :: public ttrackerpublic : tmytracker ( tmymodel * model ); virtual ˜ tmytracker (); virtual ttracker * trackfirsttime ( const tevent & amp ;); virtual ttracker * trackcontinue ( const tevent & amp ;); virtual void tracklasttime ( const tevent & amp ;); private : tmymodel * fmymodel ; tmycommand fmycommand ;}; tmytracker :: tmytracker ( tmymodel * model ){ fmodel = model ;} ttracker * tmytracker :: trackfirsttime ( const tevent & amp ; event ){ fmycommand . setdata ((( const tmyevent & amp ;) event )-& gt ; getsomedata ()); fmymodel -& gt ; processdofirsttime ( fmycommand ); return this ;} ttracker * tmytracker :: trackcontinue ( consttevent & amp ; event ){ fmycommand . setdata ((( const tmyevent & amp ;) event )-& gt ; getsomedata ()); fmymodel -& gt ; processdocontinue ( fmycommand ); return this ;} void tmytracker :: tracklasttime ( consttevent & amp ;){ fmycommand . setdata ((( const tmyevent & amp ;) event )-& gt ; getsomedata ()); fmymodel -& gt ; processdolasttime ( fmycommand );} ______________________________________ the command &# 39 ; s job is to incrementally modify the model . instead of being executed just once , the command is executed incrementally . in addition to being streamed once , the command is updated with command delta objects . there are two sets of methods used to update the command . their calling sequences are presented below : the rule for writing a streamout . . . delta method is to stream out any data which has changed during this track phase . the streamoutcontinuedelta method returns true if this delta is required . some trackers , like a rubber - band - line tracker , can skip any or all of their intermediate steps . these kind of trackers should always return false from streamoutcontinuedelta . other kinds of trackers , like a polygon sketching tracker , might return false during the dragging portion of a track , but return true each time a vertex is clicked . the rule for writing a streamin . . . delta method is to stream in the data which was streamed out by the corresponding many commands need to pass exactly the same information during each phase of tracking . to simplify writing these commands , the default implementation of the stream . . . delta methods is similar to the following : ______________________________________booleantcommand :: streamoutcontinuedelta ( tstream & amp ; stream ) const * this & gt ;& gt ;= stream ; return false ; // continue deltas are notrequired , by default } voidtcommand :: streamincontinuedelta ( tstream & amp ; stream ){ * this & lt ;& lt ;= stream ;} void tcommand :: streamoutlastdelta ( tstream & amp ; stream ) const { streamoutcontinuedelta ( stream );}/ void tcommand :: streaminlastdelta ( tstream & amp ; stream ){ streamoutcontinuedelta ( stream );} ______________________________________ given these default methods , you can override the operator & gt ;& gt ;= and operator & lt ;& lt ;= methods to do the streaming for all three track phases . when the tracker calls tmodel :: processdofirsttime () the command argument is flattened and sent to the model server . from there it is flattened again and sent to each of the cached models . at each model the command &# 39 ; s handledofirsttime () method is executed . when the tracker calls tmodel :: processdocontinue () the command argument is asked to stream out the delta information . the command delta is sent to the model server . from there the delta is sent to each of the cached models . at each model the delta is streamed into the local copy of the command . then the command &# 39 ; s handledocontinue () method is executed . when the tracker calls tmodel :: processdolasttime () the command argument is asked to stream out the delta information . the command delta is sent to the model server . from there the delta is sent to each of the cached models . at each model the delta is streamed into the local copy of the command . then the command &# 39 ; s handledolasttime () method is executed . there are two ways an incremental command can finish its extended do phase . the standard way is for tmodel :: processdolasttime () to be called . the other way is for the collaborator who is doing the tracking to unexpectedly leave the collaboration . in that case the command on the model server has it &# 39 ; s handlecollaboratordied () method called . after the extended do phase is finished , the command is expected to be in the same state as if it &# 39 ; s handledo () method was called . the command at the model server is handed on to the command manager for logging and undo purposes . the commands at the cached models are deleted . by default , commands are sent to the model server before being applied to local cached models . this allows the handlemodelserverdo () method a chance to interact with the model server . while this greatly simplifies implementing some kinds of commands ( like cut & amp ; paste , and object creation commands ), the round - trip delay needlessly slows down most tracking commands . if your command does not rely upon the state of the model server , you can speed up the local execution of the command by overriding allowsearlydo and returning true . this will allow the document architecture to execute your command immediately , before sending it to the model server . allowsearlydo is checked every time a command is executed , including the continue and last - time phases of tracking . you are permitted to return a different answer every time this method is called . some commands have no well - defined termination conditions . text - entry tracking , for example , ends only when another command is started . to support these types of commands , the model will automatically finish pending incremental commands when another command is processed . the model does this by calling the tcommand :: finishtracking method of the current tracking command . virtual void tcommand :: finishtracking (); finishtracking &# 39 ; s default behaviour is something like this : note that most trackers will delete themselves ( and their commands ) when the stoptracking method is called . this means that you should not refer to any of your instance variables ( or call any virtual methods ) after calling stoptracking . to support this behaviour , you must tell the tracking command about it &# 39 ; s tracker by calling the settracker method . settracker can be invoked either during the construction of the command , or any time before the first time the command is executed by the tracker . the model &# 39 ; s job is to be a repository for data , and to post change notifications when the data is modified . the change event should have enough information about the change to allow the view to intelligently update itself . this usually includes the old , pre - change value of the selection . by convention the change notification is sent after the data is modified . the view &# 39 ; s job is to display the data in the model , and to react quickly to change notifications . if you can update the data quickly enough , then one of the simplest responses to a change notification is to do a tview :: invalidateall (). for normal views , you will have to design your view with quick response to model change notices in mind . this is not as hard as it sounds . for drawing programs a good design would employ two off - screen buffers . the first buffer would contain all the unselected objects . the second buffer would be used to composite the selected objects on top of the unselected objects . then the second buffer would be used to update the screen . while the invention has been described in terms of a preferred embodiment in a specific system environment , those skilled in the art recognize that the invention can be practiced , with modification , in other and different hardware and software environments within the spirit and scope of the appended claims .