Conversion of data and objects across classes in an object management system

Description Submit all comments and votes

BACKGROUND

The present invention concerns the conversion of data and object across classes within an object management system. The present invention is an improvement of technology disclosed within U.S. Pat. No. 4,953,080 issued on Aug. 28, 1990 to John A. Dysart et al., the subject matter of which is herein incorporated by reference.

In computer systems such as personal computers, there is a continual search to provide a user flexibility in using data. It is desirable to make data originated by one computer application available for use by other computer applications. When data is made available to another computer application, it is desirable to have the data in a format which allows for easy modification.

In the prior art applications import or export data in particular formats. However, currently available methods handle data in a manner which has only limited flexibility.

SUMMARY OF THE INVENTION

In accordance with the preferred embodiment of the present invention, a computer implemented method within an object management facility is presented. In response to a user pasting data within a clipboard to a desktop for the object management facility, a new object for the data is created. The data is placed within the new object, and an icon is displayed on the desktop for the new object. When the data is text, the new object is created to be of a type which contains text. When the data is bitmap, the new object is created to be of a type which contains bitmaps. The data is placed in the clipboard, for example, in response to a Cut command or in response to a Copy command from an application process originally processing the data. The data can be reformatted, for example, before exporting the data from the application process, before importing the data to the new object or after importing the data to the new object.

Also, in accordance with the preferred embodiment of the present invention, an alternate computer implemented method within an object management facility is presented. In response to a user selecting a first object and issuing a conversion command, classes of objects into which the first object may be converted are displayed to the user. Upon the user selecting a class of objects into which the first object is to be converting, the first object is converted into a new object of the selected class of objects. When the new object is created, data from the first object is extracted and sent to the new object. The data may be converted to a format usable by the new object. The conversion may be performed by the new object, by the first object or by the object management facility.

The present invention provides enhancements which increase the flexibility with which data may be utilized by applications. The preferred embodiment is implemented as part of the NewWave Object Management Facility available from Hewlett Packard Co., having a business address of 3000 Hanover Street, Palo Alto, Calif. 94304. The NewWave Object Management Facility runs in conjunction with Microsoft Windows which is an operating system available from Microsoft Corporation, having a business address at 16011 NE 36th Way, Redmond, Wash. 98073-9717.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computer in accordance with the preferred embodiment of the present invention.

FIGS. 2 and FIG. 3 show block diagrams which illustrate the relationship between objects, applications and data files in accordance with the preferred embodiment of the present invention.

FIG. 4 is a block diagram of an Object Management Facility (OMF) in accordance with the preferred embodiment of the present invention.

FIG. 5 is a block diagram which shows how system files within the OMF shown in FIG. 4 accesses data files and applications from memory shown in FIG. 1.

FIGS. 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 and 16 show the appearance on a screen of a session in which a user creates objects and converts data in accordance with the preferred embodiment of the present invention.

FIG. 17 is a flowchart for a computer implemented method within an object management facility in accordance with a preferred embodiment of the present invention.

FIG. 18 is a flowchart for a computer implemented method within an object management facility in accordance with another preferred embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 shows a computer 18 having a monitor 14, a keyboard 19 and a mouse 20. A portion of computer main memory 17 is shown by an arrow 9 to be within computer 18. Within computer memory main 17 is shown an object management facility (OMF) 100, an application 101, an application 102, an application 103, an application 104, an application 105 and an application 106.

Each of applications 101 to 106 store data using objects. For instance, in FIG. 2, application 101 is shown to have stored data using an object 202, an object 203, an object 204 and an object 205. Similarly, application 106 is shown to have stored data in an object 207, an object 208, an object 209 and an object 210. OMF 100 stores information indicating which objects go with which application. Objects which are associated with a single application are considered to be objects of the same type, or the same class. For instance, object 202, 203, 204 and 205 are of the same class because each is associated with application 101. Similarly objects 207, 208, 209 and 210 are of the same class because each is associated with application 106. All objects of the same class use the same application. When an application is being run by computer 18, OMF 100 informs the application which object's data the application should access. That object is then considered to be active. An object is inactive when the application the object is associated with is not being run by computer 18, or when the application the object is associated with is being run, but is not being run with the data of that object.

Active objects can communicate with each other using messages. For example if two instances of application 101 are being run by computer 18, one with the data of object 202 and the other with the data of object 203, object 202 and object 203 are both active. Therefore object 202 may send a message 211 to object 203. Similarly, if computer 18 is running application 101 with the data of object 202, and is running application 106 with the data of object 207, object 202 and object 207 are both active. Therefore, object 202 may send a message 212 to object 207.

Messages, such as message 211 and 212 may be formatted to be sent and received by all types of objects. This allows for free communication between all active objects. This also allows new object types to be defined and added to the system without requiting that the existing object types be updated to use the new type.

Each object has associated with it a data file. For instance, object 210 is shown to have associated with it a data file 221. Data in data file 221 are in a format which can be interpreted by application 106.

Each object has associated with it a list of properties. Each property has a name and a value which may be accessed by specifying the name. In addition, each class of objects has associated with it a list of properties that are common to all objects of that class. For instance, in FIG. 3, object 205 and application 101 are shown. Object 205 has associated with it a property 231, a property 232, and a property 233. Application 101 has associated with it a property 131, a property 132 and a property 133.

Property lists can contain any number of properties. Properties are used to store descriptive information about objects and classes, such as names, comments and so on.

Objects may have references to other objects. These references are called links. Links are directional: one object is called the parent, the other the child. Each link has a reference name which is a number that is assigned by the parent object to identify each of its children. All of an object's children, its children's children, and so on are collectively called that object's descendants. Similarly, an object's parents, its parents' parents, and so on, are collectively called that object's ancestors. In the preferred embodiment of the present invention, an object which may be manipulated by a user, can have zero or more children and one or more parents. An object is not allowed to become its own descendent.

In FIG. 4, OMF 100 is shown to contain seven system files: a system file 601, a system file 602, a system file 603, a system file 604, a system file 605, a system file 606 and a system file 607. An OMF interface 599 serves as interface of OMF 100 to other programs running on computer 18. System files 601-607 serve as a data base that provides various information. They provide information about object properties such as what class each object is what is the name of each object. System files 601-607 provide information about classes of objects such as what application is associated with each class of objects, what icon represents objects of a particular class and lists of what messages (such as those shown in FIG. 2) can be processed by objects of a particular class. System files 601-607 also contain information about links between parent and child objects including a list of parents and reference names of each link from a parent for each object; a list of children and reference names of each link to a child for each object; and additional information to manage data exchange across data links. Additionally, system files 601-607 contain general information such as what files are installed in the operating system for each class that is installed, and what objects have requested automatic restart when the OMF 100 is restarted.

In the preferred embodiment of the present invention system file 601 is referred to as HPOMF.CAT, system file 602 is referred to as HPOMF.CLS, system file 603 is referred to as HPOMF.XRF, system file 604 is referred to as HPOMF.PRP, system file 605 is referred to as HPOMF.INS, system file 606 is referred to as HPOMF.SDF and system file 607 is referred to as HPOMFICO.NWE. A description of each system file is now given.

System file 601, HPOMF.CAT, is also referred to as SYSCAT. HPOMF.CAT is a catalog of all the existing objects in the system. In FIG. 4, HPOMF.CAT is shown to be record oriented. HPOMF.CAT has a plurality of file records. In FIG. 4, file record 0 through file record 8 are shown, although HPOMF.CAT may contain many more file records than are shown in FIG. 4. File record 0 is a header which contains various signatures and is used to manage a list of free file records. A signature is some known value which if present indicates that the file is not corrupted. File record 1 through file record 8 and additional file records (not shown) either define an existing object, or are free. In the preferred embodiment HPOMF.CAT can grow dynamically, as more file records are needed, but cannot shrink.

File record I defines a special object called the global parent. The global parent has a form different than every other object, and may be regarded as a "pseudo" object.

In the preferred embodiment of the present invention, each record is 128 bytes in length. The fields for file record 0 are listed in Table 1 below:

TABLE 1 ______________________________________ 1FirstFreeEntry Contains the record number of the first free record in HPOMF.CAT, or "0" if there are no free records. FileId Contains the null terminated string "HPOMF.CAT". This serves as a signature. Version Contains the file format version number, which also serves as a signature. 1MaxRecordNumber Contains the number of the highest record ever allocated from within HPOMF.CAT (this highest record may or may not be free). ______________________________________

Table 2, below, contains the fields for file records in HPOMF.CAT for file records other than file record 0:

TABLE 2 ______________________________________ 1FirstFreeEntry Is "-1" if this record defines an object, otherwise this record is free and this field is the record number of the next free record, or "0" if there are no more free records. If the record is free, none of the other fields in the record is meaningful. TypeInClass Specifies the class of this object. This is the number of the record in HPOMF.CLS that indicates to which class the object belongs (see discussion of class above). SysCatFlags Specifies if the object is global if the bit masked by the number 20 (hexadecimal) is set in this byte. In the preferred embodiment all other bit positions must contain "0" and are not used. properties Specifies the number of properties, the length of the property names and the location in HPOMF.PRP of the object's properties. See the description of HPOMF.PRP below for further definition of the structure of this field. fastprops Certain object properties, such as name, are so heavily accessed that they are stored directly in this field, rather than indirectly in the properties file. Properties stored in this field are called "fast properties." ______________________________________

System file 602, HPOMF.CLS is also referred to as SYSCLASS. This system file is a list of all installed classes in the system. It is record oriented. The first record, numbered 0, is a header which contains various signatures (see above) and is used to manage a list of free records. All other records either define an installed class or are free. In the preferred embodiment HPOMF.CLS can grow dynamically, but cannot shrink.

Each file record in HPOMF.CLS is thirty-two bytes in length. HPOMF.CLS file record 0 (the header) contains the following fields listed in Table 3:

TABLE 3 ______________________________________ 1FirstFreeEntry Contains the record number of the first free record in HPOMF.CLS, or "0" if there are no free records. FileId Contains the null terminated string "HPOMF.CLS" Version Contains the file format version number. 1MaxRecordNumber Contains the number of the highest record ever allocated from within HPOMF.CLS (this highest record may or may not be free). ______________________________________

Table

4, below, contains the fields for file records in HPOMF.CLS for file records other than file record 0:

TABLE 4 ______________________________________ 1FirstFreeEntry Is "-1" if this record defines an installed class, otherwise this record is free and this field is the record number of the next free record, or "0" if there are no more free records. If the record is free, none of the other fields in the record is meaningful. ModuleFileName Specifies the name of the application associated with objects of this class as a null- terminated string. properties Specifies the number of properties, the length of the property names and the location in HPOMF.PRP of the object's properties. See the description of HPOMF.PRP below for further definition of the structure of this field. ______________________________________

In FIG. 5, the relationship of HPOMF.CAT and HPOMF.CLS is shown. Within each object entry within HPOMF.CAT, the record number, which is an object's tag, serves as an identifier 650 of data files in a mass storage memory 170 associated with the object. The field "TypeInClass" serves as an identifier 651 of the class entry in HPOMF.CLS, which identifies the class of each object. Within each class entry in HPOMF.CLS, the field "ModuleFileName" serves as an identifier 652 of the application file in mass storage memory 170 which is associated with the class.

System file 603, HPOMF.XRF is also referred to as SYSXREF. This file is a list of all the links existing in the system. It is record oriented, but does not have a header record. Each record file is either free, or defines an existing link, or is used as an overflow record from the previous record to specify additional view specification .information. Records that contain view specifications are called view specification file records. View specification file records can be identified only by a previous record which defines an existing data link; view specification file records cannot be identified by the content within a view specification file record. HPOMF.XRF is increased in size 16K bytes at a time. A newly allocated portion of HPOMF.XRF is filled with zeros. File records within HPOMF.XRF which are free or which define a link have the following fields listed in Table 5:

TABLE 5 ______________________________________ ParentTag Contains the tag (HPOMF.CAT record number) of the parent object of this link. If this field is 0, then this record does not define a link and is free. ChildTag Contains the tag of the child object of this link. If ParentTag in this record is 0, and this field is also 0, then no record beyond this record in HPOMF.XRF defines a link. RefName Contains the reference name that the parent has assigned to the link. This field is meaningless if ParentTag or ChildTag is zero. Otherwise, if the top three bits of this value are 110, the next record in the file is a view specification. ______________________________________

File records within HPOMF.XRF which are view specification file records have the following fields listed in Table 6:

TABLE 6 ______________________________________ DataId Contains the value that the child has assigned to identify the part of itself that is being viewed through the link. Snapshot Contains the tag (HPOMF.CAT record number) of the object which is the view's snapshot, or if zero, the view has no snapshot. Misc Composed of several bit fields described below: VS.sub.-- NEWDATASET Set if child has told OMF that new data is available, but has not been announced to the parent. The hexa- decimal number 8000 0000 is a mask which indicates which bits are used for this bit field. VS.sub.-- NEWDATAANNOUNCED Set if child has told OMF to announce new data to parent, but parent was in- active and was not notified. The hexadecimal number 4000 0000 is a mask which indicates which bits are used for this bit field. VS.sub.-- SNAPSHOTOLD Set if child has told OMF that the view's snapshot is out-of-date. The hexadecimal number 2000 0000 is a mask which indicates which bits are used for this bit field. VS.sub.-- WANTMESSAGES Set if child has told OMF that it wants to process view messages when snap- shot is out-of-date. The hexa- decimal number 1000 0000 is a mask which indicates which bits are used for this bit field. VS.sub.-- TEXTDISKLOC File position in HPOMF.PRP where a view's 32 character textual data ID is located. This contains zero if no textual data ID has been defined by the child. The low order five bits of the file position are always zero and are thus not stored in the Misc field. The hexadecimal number OFFF FFEO is a mask which indicates which bits are used for this bit field. VS.sub.-- INITIALIZED Set if the view specification has been initialized. If clear, all information in the view specification is zero. The hexadecimal number 0000 0010 is a mask which indicates which bits are used for this bit field. VS.sub.-- RESERVED Reserved for future expansion. The hexadecimal number 0000 0008 is a mask which indicates which bits are used for this bit field. VS.sub.-- VIEWCLASS Specifies the view class the child assigned to the view. The view class defines what view methods are available to the parent. The * hexadecimal number 0000 0007 is a mask which indicates which bits are used for this bit field. ______________________________________

System file 604, HPOMF.PRP, is also referred to as SYSPROP. HPOMF.PRP contains all the object and class properties except for the fast object properties which are contained in HPOMF.CAT. Each record in system file 601 (HPOMF.CAT) and system file 602 (HPOMF.CLS) has a properties field, as described above. Each properties field contains the fields described in Table 7 below:

TABLE 7 ______________________________________ DirDiskLoc Contains the position (byte offset) within HPOME.PRP of the property list directory. nProps Contains the number of properties in the property list. This is the number of entries in the directory entry array described below. PoolSize Contains the combined length of all the names of the properties in the property list, including a null-terminating byte for each name. This is the size of the directory name pool described below. ______________________________________

For each object and for each class, at the DirDiskLoc position in the HPOMF.PRP file is the property directory for that object or that class. The directory has two major portions: the entry array, followed by the name pool. The entry array has one entry for each property in the property list. Each entry has fields set out in Table 8 below:

TABLE 8 ______________________________________ ValueLen Specifies the length in bytes of the associated property. This can be zero. ValueDiskLoc Contains the position within HPOMF.PRP of the value of the associated property. If ValueLen is zero, this is also zero, and there is no value stored anywhere. CacheOffset This field is only used at run time and is not meaningful in the file. ______________________________________

Immediately following the entry array is the name pool. This portion of HPOMF.PRP contains the null-terminated names of properties in the property list, in the same order as the entry array. Properties may include such things as titles, user comments, date and time of creation, the user who created the object, etc.

HPOMF.PRP grows dynamically as need. At the beginning of HPOMF.PRP there is a 128 byte bitmap which controls the allocation of the first 1024 pages of HPOMF.PRP. Each page is 32 bytes in length. These pages immediately follow the bit map. The bitmap is an array of words with the most significant bit of each word used first. Thus, bits 15 through 0 of the first word of the bitmap control the allocation of pages 0 through 15 of the file, respectively.

When storage in the first 1024 pages is insufficient, a second bitmap is added to the file following page 1023. This bitmap controls the allocation of pages 1024 through 2047, which immediately follow the second bitmap. Additional bitmaps and pages are added in the same way, as needed.

Each directory and property value is stored as a single block in the file, i.e., as a contiguous run of pages that are all allocated in the same bitmap. This causes the restriction that no directory or value can exceed 32K bytes (1024 times 32) in length.

System file 605, HPOMF.INS, is also referred to as SYSINSTL. HPOMF.INS contains a list of the files that were copied to the system when each class was installed. This information is used so that these files can be deleted when the class is de-installed.

The very beginning of HPOMF.INS is a double word value which serves as a validity/version identifier. In the preferred embodiment the value of this double word must be 0101ABCD hex to be valid. In Table 9, this number is stored as shown because of the protocols for storage in the particular processor used, i.e. an 80286 microprocessor made by Intel Corporation.

Following the double word comes a series of variable length records. There is one record for each installed class. The first word of each record is the length of the rest of the record, in bytes. This is followed by the null-terminated class name of the installed class. Then follows the file names of the files copied to the OMF directories, each terminated by a null byte, and preceded by a byte which gives the length of the file name, including the length byte and the null terminator. If the file name begins with the special character "*", the file is assumed to be located in the HPNWPROG directory. If the file name begins with the special character "+" the file is assumed to be located in the HPNWDATA directory.

For example, assume two classes are installed: class "AB" and class "CDE". Class "AB" caused two files to be installed: "Z" to HPNWPROG directory 668 and "YY" to the HPNWDATA directory. Class "CDE" caused 1 file to be installed: "XXX" to HPNWPROG directory 668. Given this case Table 9 below shows the contents of HPOMF.INS for this example:

TABLE 9 ______________________________________ offset content comments ______________________________________ 0 CD AB 01 01 File header/version check 4 0C 00 Length of AB record (12 decimal) 6 41 42 00 "AB" + Null 9 04 Length of length byte "Z" + Null A 2A 5A 00 "Z" + Null D 05 Length of length byte + "+YY" + Null E 2B 59 59 00 "+YY" + Null 12 0A 00 Length of CDE record (10 decimal) 14 43 44 45 00 "CDE" + Null 18 06 Length of length byte + "*XXX" + Null 19 2A 58 58 58 00 "*XXX" + Null ______________________________________

System File 606, HPOMF.SDF is also referred to as the "shutdown file". HPOMF.SDF exists only when the system has been cleanly shut down. It is deleted as the system starts, and created as it shuts down. On startup, if this file is missing, OMF assumes that the last session ended abnormally, and so it goes through its crash recovery procedures to validate and repair the system files as best it can. The system files can be in an invalid but predictable state on a crash. These errors are corrected without user intervention. Certain other kinds of file consistency errors are detected, but are not really possible from an "ordinary" system crash. These errors are in general not correctable and the OMF will not allow the system to come up in this case.

If HPOMF.SDF is present, it contains a list of objects. When the system is being shut down normally, each object which is active at the time can request that the OMF restart them when the system is restarted. The list of objects, then is the list of tags of objects which have requested that they be restarted when the system is restarted.

The first word in HPOMF.SDF is a flag word. If this word is nonzero, OMF will execute its crash recovery code even though HPOMF.SDF exists. Normal shutdown will set this flag when producing the file if some serious error occurred in the session being ended.

After the first word, the rest of the file is a sequence of three byte records. The first two bytes of each record contain the tag of the object to be restored. The least significant byte is first. The third byte is not used in the preferred embodiment, and is zero.

For example, if the system is shut down cleanly in the last session and two objects, having tags of 2 and 7, respectively, have requested restart, the contents of HPOMF.SDF will be as set out in Table 10 below.

TABLE 10 ______________________________________ offset content comments ______________________________________ 0 00 00 Indicates no crash recovery needed 2 02 00 Tag of first object to restart 4 00 Unused and reserved 5 07 00 Tag of second object to restart 7 00 Unused and reserved ______________________________________

System file 7, HPOMFICO.NWE, is a Microsoft Windows dynamic library executable file which contains a dummy entry point and no data. Microsoft Windows is a program sold by Microsoft Corporation, having a business address at 16011 NE 36th Way, Redmond, Wash. 98073-9717. HPOMFICO.NWE also contains as "resources" the icons of each installed class. OMF modifies HPOMFICO.NWE directly during run time, and loads and unloads it to get the icon resources from it. The format of HPOMFICO.NWE is defined in Microsoft Windows documentation distributed by Microsoft Corporation.

FIG. 6 shows a screen displayed on monitor 14. A NewWave OMF window 300 has a menu bar 301. Within OMF window 300, icons are displayed which each represent an object. For example, an icon 302, an icon 303, an icon 304, an icon 305, an icon 306, an icon 307 and an icon 308 are shown. Icons 302 through 307 represent NewWave Tools.

Icon 308 represents an object DEMO associated with a word processing program. Object DEMO may be opened, for example, by using mouse 20 to place a cursor 310 over icon 308, and depressing a button on mouse 20 twice in quick succession.

FIG. 7 shows an open window 311 for Object DEMO. Window 311 includes a menu bar 312. FIG. 8 shows the selection of text 315 within window 311. For example, text 315 is selected using cursor 310 and mouse 20. FIG. 9 shows text 315 being copied to a clipboard using cursor 310 to select "Copy" from pull-down menu "Edit" on menu bar 312. FIG. 10 shows the contents of the clipboard being copied to OMF window 300 by selecting "Paste" from pull-down menu "Edit" on menu bar 301. FIG. 11 shows an icon 309 for an Untitled object appearing within OMF window 300.

Object Untitled may be opened, for example, by using mouse 20 to place cursor 310 over icon 309, and depressing a button on mouse 20 twice in quick succession. FIG. 12 shows an open window 321 for Object Untitled. Window 321 includes a menu bar 322. Within 321, text 325 appears. Text 325 is identical to text 315.

The above discussion shows a user view of data to object conversion. The preferred embodiment of the present invention allows, upon request, the creation of an object from a bitmap or text to be turned into an object.

In order to implement the preferred embodiment of the present invention in an application, various modifications must be made to an application, particularly, two routines are added to an application program interface (API) for the application. These are NW.sub.-- MakeClipboardFormat and NW.sub.-- IsClipboardFormatAvailable. In addition, the APIs for applications which support the preferred embodiment of the present invention must be installed with the correct conversion information in one or more of the following properties: PROP.sub.-- CLASS.sub.-- DATA.sub.-- FMT, PROP.sub.-- ACCEPT.sub.-- DATA.sub.-- FMTS and PROP.sub.-- RENDER.sub.-- DATA.sub.-- FMTS. These properties are stored in the installation, or IN$ file for the class, as described in more detail below.

For an object to be converted to data, the object must either have a native data file format of TEXT or support the RENDER.sub.-- DATA method (see below) for the desired data format. For data to be converted to an object, the (new) object must either have a native data file format of TEXT, and TEXT has to be on the clipboard, or the (new) object must support the ACCEPT.sub.-- DATA method (see below) for one of the formats on the clipboard.

When there is data on the clipboard and a user requests a paste of data to be made to OMF window 300, the routine NW.sub.-- MakeClipboardFormat is called with a desired format of CFN.sub.-- OBJECT. NW.sub.-- IsClipboardFormatAvailable can be called to find out if CFN.sub.-- OBJECT is available. The new object will be made according to the following rules, in priority order. First, if the data on the clipboard was put there by an NewWave OMF object (native or encapsulated), and the object is active, then the object created will be the same class, if possible (i.e., if the class supports the necessary methods and properties).

If the object cannot be created with the same class, the class of the object will depend on the format of data on the clipboard. If the data on the clipboard is text, a Textnote object will be constructed. If the data on the clipboard is not text, then all the classes will be searched for an appropriate object class which supports the particular data format via the ACCEPT.sub.-- DATA method.

When a match is found, then the routine will stop looking at the formats on the clipboard. The enumeration tries to ensure that the richest format possible is used, since normally applications put their richest format first on the clipboard.

The following Table 11 is a description of the total algorithm which converts data from an application to the OMF desktop window 300, or for an application that supports PASTE:

TABLE 11 ______________________________________ 1. The user issues a Cut or Copy command from a NW object or an MSWindows application. The selection can be either object or data. 2. The destination gets ready to display the Edit menu. It wants either the CFN.sub.-- OBJECT format, or data of a certain format. It asks the OMF, via the NW.sub.-- IsClipboardFormatAvailable routine, if the format is available. (It does this so it knows whether or not to gray the Paste item on the Edit menu.) 3. The NW.sub.-- IsClipboardFormatAvailable routine first looks to see if there is anything on the MSClipboard. If not, Fail is returned. If the requested format is already on the MSClipboard, it returns Success. If not, then it decides whether or not it can provide that format from the current Clipboard contents. 4A. If the requested format is data AND there is an object on the Clipboard, it gets the class of that object. It then looks at the class properties of the object to see if it can export data of the type requested, or, if TEXT is requested, if its native data file format is TEXT. If so, Success is returned, else Fail. If there is no object on the clipboard, Fail is returned. 4B. If an object is requested, AND there is data on the MSClipboard, then the routine follows the Object Conversion algorithm given on the preceding page to see if an object could be constructed from the formats on the clipboard. If so, Success is returned, else Fail. If there is already an object on the clipboard, Success is returned. 5. If the destination is directed to Paste by activation of the Edit menu or by a shift- insert, it then asks NW to make the requested format via a new routine, NW.sub.-- MakeClipboardFormat. 6. This second routine first looks to see if the requested format is already available. If an object is requested, it also verifies that the object supports the requested methods. If the format is available, it returns without doing anything. 7A. If data is requested, and there is an object on the clipboard, then if the object's native data file format is the same as the format requested, and the format requested is TEXT, the data file is read and put on the clipboard. If not, then the routine looks to see if the object can export data of the format requested via the Render Data method. If so, then the object is sent the Render Data message. 7B. If an object is requested, a class is searched for. If the desir