US 5,911,066 AGrant
Data Transfer Utilizing a Single Functionally Independent Data Transfer Mechanism
Issue Date:1999-06-08
•51 Claims
•19 Drawing Sheets
Abstract
An improved data transfer mechanism is provided. In a preferred embodiment of the present invention, a uniform data transfer mechanism is used by each computer program performing data transfer. The uniform data transfer mechanism of the preferred embodiment of the present invention provides a communication mechanism and a flexible and robust interface to support all existing and future data transfer applications.
Metadata
Assignee
- Microsoft Corporation
Inventors
- Antony S. Williams
- Robert G. Atkinson
Application Information
Application Number:US 6323073
Filing Date:1996-04-15
Priority Date:1994-02-22
Art Unit:275
Classifications
IPC:
G06F 15163
Field of Search:
395345364650;600;700;157;161;680;670;710;674340;145234;236.8
Patent Drawings (19 sheets)
Description
Technical Field
The present invention relates generally to data processing systems and, more particularly, to a uniform mechanism for transferring data within a data processing system.
Background of the Invention
In conventional computer systems, data transfer is application specific. In other words, a computer program is responsible for handling the data transfer that is required by an application of data transfer functionality ("application"). Two examples of such applications of data transfer functionality are drag-and-drop and cut-and-paste. Drag-and-drop refers to when a computer user selects data contained within a data source and moves the mouse to a data sink while keeping the mouse button depressed. The data source and the data sink are computer programs within the computer system which contain or accept data. An example of a data source or data sink is a file editor or a word processing document. When the indicator on the computer display, which reflects mouse movement ("mouse pointer"), appears to be pointing to the data sink, the user releases the depressed mouse button and the selected data appears to be inserted into the data sink. Cut-and-paste refers to when a computer user selects data from within a data source and performs a cut operation (typically invoked through a pull-down menu). The computer user then selects a position in the data sink, and performs a paste operation (typically invoked through a pull-down menu). The result of a cut-and-paste application is that data is extracted from the data source and is inserted into the data sink. In order to understand how a data sink and a data source handle the drag-and-drop and cut-and-paste applications, drag-and-drop and cut-and-paste are examined in more detail below.
FIG. 1 depicts a conventional computer system for performing a drag-and-drop application. The memory 102 of the computer system contains a data source 104, which contains data 110; a global memory 108; a window manager 112 and a data sink 106. The global memory 108 is an area of memory that is accessible to all computer programs in a state of operation. Global memory may be contrasted against local memory wherein local memory is memory local to the computer program (i.e., within the address space of the computer program). The window manager 112 is a computer program responsible for performing all computer display-related operations. FIG. 2 depicts a flowchart of the steps performed by a conventional computer system for performing a drag-and-drop application. When a drag-and-drop application is performed, the computer user first selects the data 110 within the data source 104 by typically using a mouse or other pointing device (step 202). Selecting data refers to highlighting data 110 within the data source 104. The computer user then drags the selected data 110 to the data sink 106 (step 204). Dragging refers to the computer user (hereafter "user") depressing the mouse button, while the mouse pointer is positioned on the selected data 110, and moving the mouse while keeping the mouse button depressed. After the user drags the data 110 to the data sink 106, the data source 104 converts the data 110 into a format acceptable to the global memory 108 and passes the data 110 to the window manager 112 (step 206). When the data 110 is passed to the window manager 112, the window manager 112 stores the data 110 into the global memory 108. After storing the data 110 into the global memory 108, the window manager 112 transfers the data 110 from the global memory 108 to the data sink 106 (step 208). Upon receiving the data 110, the data sink 106 converts the data 110 into a format acceptable to the data sink 106 (step 210).
The cut and paste application is similar to the drag and drop application in that a data sink and a data source performing the cut and paste application also form a connection and transfer data. FIG. 3 depicts a conventional computer system for performing the cut-and-paste application. The memory 102 of the computer system contains a data source 104, which contains data 110; a clipboard 302; and a data sink 106. The clipboard 302 is responsible for maintaining an area of global memory used for temporary storage. During a cut-and-paste application, the user selects data 110 from the data source 104, invokes a cut operation (typically by using a pull-down menu), inserts the cursor into the data sink 106 and invokes the paste operation (typically by using a pull-down menu). Both the cut and the paste operations are provided by the clipboard 302 and are well known in the computer industry. FIG. 4 depicts a flowchart of the steps performed by a conventional computer system for performing the cut-and-paste application. First, the user selects data 110 from the data source 104 and performs a cut operation (step 402). The data 110 is then converted into a format acceptable to the clipboard 302 (step 404). After the data 110 has been converted, the data 110 is copied to the clipboard 308, wherein the data 110 then resides within global memory (step 406). Then, the user selects a location within the data sink 106 and invokes the paste operation (step 408). The data sink 106 transfers the data 110 from the clipboard 302 to the location in the data sink 106 selected by the user (step 410).
As indicated above, in both the cut-and-paste and the drag-and-drop applications, the data source and the data sink form a logical connection through either the clipboard 302 or the window manager 112. Then, after the connection is established, the data 110 is transferred. This two-step process requires the developers Of computer programs which perform applications of data transfer functionality to create, for each application, both a connection component to establish a connection and a data transfer component to perform the data transfer. Thus, the developers of computer programs which support applications of data transfer functionality must implement a data transfer component for every application supported.
Summary of the Invention
In accordance with a first aspect of the present invention, a method is executed in a computer system. In accordance with this method of the first aspect of the present invention, the computer has a connection mechanism, a uniform data transfer mechanism and a plurality of computer programs. In order to perform data transfer between two computer programs, this method establishes a connection between the computer programs transferring data and invokes the uniform data transfer mechanism to perform the data transfer.
In accordance with a second aspect of the present invention, a communication mechanism is provided that contains a connection component and a data transfer component. The data transfer component further contains a GetData component, a GetDataHere component, a QueryGetData component, a GetCanonicalFormat component, a SetData component, a EnumFormat component, an Advise component, an UnAdvise component and an EnumAdvise component.
Brief Description of the Drawings
FIG. 1 depicts a conventional computer system for performing a drag-and-drop application
FIG. 2 depicts a flowchart of the steps performed by a conventional computer system for performing a drag-and-drop application.
FIG. 3 depicts a conventional computer system for performing a cut-and-paste application.
FIG. 4 depicts a flowchart of the steps performed by a conventional computer system for performing a cut-and-paste application.
FIG. 5 depicts a computer suitable for practicing the preferred embodiment of the present invention.
FIG. 6 depicts a component object model used in the preferred embodiment of the present invention.
FIG. 7 depicts a functional diagram of the uniform data transfer mechanism of the preferred embodiment of the present invention.
FIG. 8 depicts a flowchart of the steps performed by a GetData method of an IDataObject interface of the preferred embodiment of the present invention.
FIG. 9 depicts a flowchart of the steps performed during an advisory connection in the preferred embodiment of the present invention.
FIGS. 10A and 10B depict a flow chart of the steps performed by a client performing an application of data and transfer functionality utilizing the uniform data transfer mechanism of the preferred embodiment of the present invention.
FIG. 11 depicts a computer system for performing a cut-and-paste application utilizing the uniform data transfer mechanism of the preferred embodiment of the present invention.
FIG. 12 depicts a flowchart of the steps performed by the computer system of FIG. 11.
FIG. 13 depicts a computer system for performing a drag-and-drop application utilizing the uniform data transfer mechanism of the preferred embodiment of the present invention.
FIG. 14 depicts a flowchart of the steps performed by the computer system of FIG. 13.
FIG. 15 depicts a computer system for performing real time data transfer utilizing the uniform data transfer mechanism of the preferred embodiment of the present invention.
FIG. 16 depicts a computer system for performing custom marshalling utilizing the uniform data transfer mechanism of the preferred embodiment of the present invention.
FIG. 17 depicts a computer system for performing programmatic transfer utilizing the uniform data transfer mechanism of the preferred embodiment of the present invention.
FIG. 18 depicts an alternative computer system for performing programmatic transfer utilizing the uniform data transfer mechanism of the preferred embodiment of the present invention.
Detailed Description of the Invention
The preferred embodiment of the present invention provides for a uniform data transfer mechanism that may be used by any computer program to transfer data. Thus, the code that implements this mechanism may be reused by multiple computer programs and these computer programs need not include their own code to handle data transfer. In addition, within a computer program that performs many applications of data transfer functionality, the computer program needs only to use one data transfer mechanism. Thus, computer programs only need to implement the connection component associated with data transfer applications. The preferred embodiment also provides a robust and flexible interface into the uniform data transfer mechanism so that computer programs may make easy and efficient use of the uniform data transfer mechanism.
FIG. 5 depicts a computer suitable for practicing the preferred embodiment of the present invention. The computer 500 contains a central processing unit (CPU) 502, a memory 504 and a permanent storage device 506. Those skilled in the art will appreciate that the computer 500 may also include additional components. The CPU 502 is responsible for transferring computer programs between the permanent storage 506 and the memory 504, and executing the computer programs once resident within the memory 504. The permanent storage device 506 is a non-volatile storage device for storing information in between invocations of the computer system. Although the preferred embodiment of the present invention is described as being used on a single computer system, one skilled in the art will appreciate that the preferred embodiment can be used on a distributed system wherein each computer is connected by a local area network or a wide area network.
The preferred embodiment of the present invention is designed to operate in an object-oriented environment, such as an environment that supports the Microsoft OLE 2.0 ("OLE") protocol established by Microsoft Corporation of Redmond, Wash. The environment in which the preferred embodiment of the present invention is practiced follows an underlying component object model. An object is a logical structure that includes data structures for holding data and may include functions that operation on the data held in the data structures. An object may hold just data and not include code for manipulating the data. An object is a useful structure for encapsulating data and behavior into a single logical entity.
Objects are organized into "classes." An object class is a group of objects with similar properties and common behavior. Each object is a member of a class and constitutes an instance of the object class. All members of a class include at least the properties defined for the object class, but the value of these properties may vary among the objects of the object class.
Another concept exploited in the preferred embodiment of the present invention is the notion of an "interface." An interface is a named set of logically related functions ("methods"). An interface lists signatures (such as parameters) for a set of methods. For instance, an example interface may define the signatures for various methods that are used to display an object on a video display. An interface does not provide code for implementing the methods; rather, the code for implementing the methods is provided by objects. Objects that provide the code for implementing the methods of an interface are said to "support" the interface. The code provided by an object that supports an interface must comply with the signatures provided within the interface. In the C++ programming language, an interface constitutes a set of virtual functions. Although the preferred embodiment of the present invention is described as being implemented in an object-oriented environment, those skilled in the art will appreciate that the present invention may also be practiced in non-object-oriented environments as well.
The basic concepts of the component object model may be explained relative to the block diagram of FIG. 6. The memory 504 of the computer contains a client 602 and a server 604. The client 602 and the server 604 are computer programs in a state of operation. The server 604 contains an object 606. The client 602 uses an interface provided by the object 606 to manipulate the object 606. The client 602 does not know of the implementation of the object 606 or the server 604. Only the server 604 knows of the implementation of the object 606 and how to manipulate the object 606. Since the client 602 does not know the implementation of the object, the client 602 is data independent. Data independence allows the developer of the client 602 to write code which will allow for the support of new types of data and interactions with new computer programs without having to change the code of the client 602. Since the internal representation of the object 606 is hidden from the client 602, the client 602 manipulates the object through the use of an "interface."
All objects in the component object model are required to support the IUnknown interface. Since all objects support the unknown interface, when a client 602 wishes to manipulate an object 606, the client 602 first accesses the IUnknown interface in order to access the interface that provides the appropriate methods to perform the desired manipulation. One method contained within the IUnknown interface is the QueryInterface method. The client 602 uses the QueryInterface method of the IUnknown interface to obtain a pointer to a desired interface from the object 606. If the object 606 supports the requested interface, the object 606 returns a pointer to the requested interface to the client 602. After receiving a pointer to the requested interface, the client 602 can directly manipulate the object 606 using the methods contained in the requested interface.
Since the client 602 does not know of the implementation of the methods nor does the client 602 know of the internal representations of the object 606, the code of the client 602 is flexible and can support new forms of objects without having to change because the code of the client 602 is data independent.
Consider an example where a client 602 is a word processing document, a server 604 is a spreadsheet program, and an object 606 is a range of cells within the spreadsheet program. Thus, by using the component object model, the object 606 may appear as part of the client 602 to the user and may be manipulated by the user while using the client 602. The user may modify the cells in the object 606 by using the client 602, and the client 602 invokes the methods that implement the modifications in order to manipulate the object 606.
The preferred embodiment of the present invention provides a uniform data transfer mechanism ("UDT"). The UDT provides a mechanism and interface to computer programs so that the computer programs may transfer data in a uniform manner after a connection is established. Thus, the developers of computer programs which perform applications of data transfer functionality using UDT only implement a connection component for each application, not the data transfer component. As a result, the computer programs are easier to implement. Since the preferred embodiment is designed for use with all applications of data transfer functionality, the preferred embodiment provides a robust interface to support all existing applications as well as future applications.
FIG. 7 depicts a functional diagram of UDT of the preferred embodiment of the present invention. The preferred embodiment of the present invention uses UDT 708 to provide a uniform mechanism for transferring data for any application of data transfer functionality. Examples of such applications are a cut-and-paste application 702, a drag-and-drop application 704 and, more Generally, other applications 706 which transfer data.
As mentioned above, the preferred embodiment of the present invention provides interfaces for facilitating UDT. For purposes of explaining how the UDT mechanism works, the major interfaces that are provided will be described in more detail below. The preferred embodiment of the present invention provides a DLL that provides an IDataObject Interface. The IDataObject interface groups several methods that are useful to an object that transfers data. Upon receipt of a pointer to the IDataObject interface, the client may use UDT 708.
In the IDataObject interface, the FORMATETC structure is used in many methods. The FORMATETC structure is used to request or define the format and aspect ("characteristics") of the data being transferred in UDT 708 as well as other information. When a client requests specific characteristics for a data transfer, the client is said to be requesting data according to the preferences of the client. The FORMATETC structure is defined in Code Table No 1. All code described herein is provided in the C++ programming language.
The cfFormat member of FORMATETC describes the format in which data being transferred is conveyed. The ptd member of the FORMATETC structure specifies the device for which the data being transferred is destined. The dwAspect member of the FORMATETC structure allows a client to request data from an object in different aspects. An aspect is a representation of an object. An object can have many representations such as a browsing representation, wherein the representation is appropriate for viewing only, or a print representation wherein the data in an object is formatted for printing. Therefore, for example, by appropriately setting the dwAspect member of the FORMATETC structure, a client may request the browsing aspect of an object. There are four values appropriate for the dwAspect member: DVASPECT.sub.-- CONTENT, DVASPECT.sub.-- THUMBNAIL, DVASPECT.sub.-- ICON, and DVASPECT.sub.-- DOCPRINT. Use of the DVASPECT.sub.-- CONTENT value in dwAspect member signifies a request for a representation of an object appropriate for the displaying of the object. Use of the DVASPECT.sub.-- THUMBNAIL value in the dwAspect member signifies a request for a representation of an object suitable for browsing. Use of the DVASPECT.sub.-- ICON value in the dwAspect member signifies a request for an iconic representation of the object. Use of the DVASPECT.sub.-- DOCPRINT value in the dwAspect member signifies a request for a printed representation of the object (i.e., formatted for a sequence of pages). The lindex member of the FORMATETC structure indicates a range of pages in the printed representation of the object when the dwAspect member is a DVASPECT.sub.-- DOCPRINT value.
The tymed member of the FORMATETC structure indicates the requested medium through which the client would like to receive the data. The values for the tymed member correspond to bit positions, thus a client can request any combination of the appropriate values by "ORing" the values together. The values for the tymed member thus enable a client to request that data be transferred over one of a number of media. The suitable values for the tymed member of the FORMATETC structure are defined in Code Table No. 2.
Another structure used in the IDataObject interface is the STGMEDIUM structure. The STGMEDIUM structure is used to define the particular medium upon which the data is to be stored and, therefore, contains two members. The first member indicates the type of medium and, thus, the values for the first member are the same as those described above for the tymed member of the FORMATETC structure. The second member of the STGMEDIUM structure is a reference to the medium used for transferring the data. Although the tymed member of the FORMATETC structure and the STGMEDIUM structure are described with reference to specific media, one skilled in the art will appreciate that other media can be used.
The IDataObject interface provides nine methods which use the above-described structures. The nine methods of the IDataObject interface include: GetData, GetDataHere, QueryGetData, GetCanonicalFormatEtc, SetData, EnumFormatEtc, DAdvise, DUnadvise and EnumDAdvise. The IDataObject interface is defined in Code Table No. 3. Each method of the IDataObject interface is discussed separately below.
The GetData method of the IDataObject interface allows a client to retrieve data from an object that supports the IDataObject interface. The client may retrieve data from the object according to the preferences of the client. Thus, the client may specify a specific format, a specific aspect, a format for a specific device and conveyance through a specific medium. The parameters of the GetData method are defined in Code Table No. 4.
The pformatetc parameter is a pointer to a FORMATETC structure and the members of the FORMATETC structure specify the preferences of the client for receiving the data. The tymed member of the pformatetc parameter indicates at least one medium upon which the client would like to receive the data. If the server can support the requested preferences and one of the requested media, the server returns the requested data on the medium specified by the pmedium parameter. Thus, the pmedium parameter is an output parameter. Otherwise, if the server cannot support the preferences or the requested media, the GetData method returns an error. The return value parameter of the GetData method is a value indicating a successful completion or unsuccessful completion of the GetData method. An example of an error that may occur is when the server cannot convert the data into the requested format.
FIG. 8 depicts a flowchart of the steps performed by the GetData method of the IDataObject interface of the preferred embodiment of the present invention. Upon invocation, the GetData method determines the preferences of the client by accessing the structure referenced by the pformatetc parameter (step 802). The GetData method next determines the media upon which the client would like to receive the requested data by accessing the tymed member of the FORMATETC structure referenced by the pformatetc parameter (step 804). The GetData method then determines whether the server is able to support the requested preferences and one of the requested media (step 806). Since the GetData method was implemented by the developers of the server in which the object is contained, the GetData method knows of the media and preferences that can be supported by the object and the server. If the server is able to support the requested preferences and one of the requested media, the server returns the data according to the requested preferences on a requested medium to the client (step 808). If, however, the server is unable to support either the preferences or one of the requested media, the GetData method returns an error to the client (step 810).
The GetDataHere method of the IDataObject interface permits a client to specify the medium that is to be used for transferring the requested data. Since the method receives a reference to the medium as a parameter, the method only copies the requested data onto the medium specified by the parameter. However, the method must still determine whether the server can support the requested preferences. The GetDataHere method is defined in Code Table No. 5.
The pformatetc parameter of the GetDataHere method is a pointer to a FORMATETC structure which specifies the preferences of the client for the requested data. The pmedium parameter is a reference to the medium to be used for transferring the requested data. The pmedium parameter is an input parameter. The return.sub.-- value parameter of the GetDataHere method is an output parameter indicating a successful completion or unsuccessful completion of the GetDataHere method. One example of an error that may occur is when the server is unable to support the requested format for the requested data.
Upon invocation of the GetDataHere method, the GetDataHere method first determines if the requested preferences for the requested data can be supported by the server. If the requested preferences can be supported by the server, the GetDataHere method transfers the requested data over the medium specified by the pmedium parameter and returns a value indicating success in the return value parameter. If the requested preferences cannot be supported by the server, the GetDataHere method returns a value in the return value parameter indicating that an error occurred.
The QueryGetData method in the IDataObject interface allows a client to test whether the server would be able to return specified data by the GetData method according to specified preferences on a specified medium. The definition of the QueryGetData method is provided in Code Table No. 6.
The pformatetc parameter of the QueryGetData method is a pointer to a FORMATETC structure. The FORMATETC structure referenced by the pformatetc parameter contains the preferences requested by the client including a medium for transferring the data. The return.sub.-- value parameter of the QueryGetData method contains a value indicating a successful or unsuccessful completion of the QueryGetData method. An error that may be referenced in the return.sub.-- value parameter is the inability of the server to support the requested format, the requested aspect or the requested medium.
The GetCanonicalFormatEtc method of the IDataObject interface allows a client to query an object to determine the characteristics of the data that will be returned to the client for a given input FORMATETC parameter. Thus, the GetCanonicalFormatEtc method gives the client the ability to determine whether the client will receive data in a format for which the client has already received data. Therefore, if the client has already requested data from an object and has received the requested data in a specific format, before requesting (by GetData) a new format for the received data, the client can use the GetCanonicalFormatEtc method to determine whether the object will return the new request for the data in the same format as the previous request for the data. Use of the GetCanonicalFormatEtc method by a client can save the client from using memory or disk space for unnecessary duplicate copies of similar data having similar characteristics. The definition for the GetCanonicalFormatEtc method is provided in Code Table No. 7.
The pformatetcIn parameter is a pointer to a FORMATETC structure that contains the preferences of the client for the requested data. The pformatIn is an input parameter. The pformatetcOut parameter is a reference to a FORMATETC structure which contains the characteristics of the requested data that will be returned for the given pformatetcIn parameter. The return.sub.-- value contains an indication of whether the characteristics that can be supported by the server is the same as the characteristics specified by pformatetcIn.
The SetData method of the IDataObject interface allows a client to send data to an object according to specified characteristics over a specified medium. The definition for the SetData method is provided in Code Table No. 8.
The pformatetc parameter of the SetData method is a pointer to a FORMATETC structure which contains the characteristics of the data sent to an object. The pmedium parameter is a reference to the medium used for transferring the data. The fRelease parameter of the SetData method indicates whether the client or the server is responsible for releasing the medium specified by the pmedium parameter after the data has been sent to the object. The return.sub.-- value contains a value indicating a successful or unsuccessful completion to the SetData method.
The EnumFormatEtc method of the IDataObject interface allows a client to enumerate the available characteristics of data sent to or received from an object. This method allows a client, before requesting data, to determine whether the data that the client requests can be received according to the preferences of the client. The definition of the EnumFormatEtc method is provided in Code Table No. 9.
The wDirection parameter of the EnumFormatEtc method is used for setting a value indicating whether the request is for characteristics supported for a SetData or a GetData method. The ppenumFormatEtc is a pointer to a pointer to an enumerator which contains the available formats for the data in the object. The return value is a value indicating a successful or unsuccessful completion of the EnumFormatEtc method.
The DAdvise method of the IDataObject interface allows a client to establish an advisory connection between an object and an advisory sink. An advisory connection is a logical connection between an advisory sink and an object where, when the data of the object changes, the server notifies the advisory sink of the change. The advisory sink may be a client, server, object or other software entity. In calling the DAdvise method, the client requests the composition of the notification and how the notification will be performed. For example, the client can request that the object suppress the transfer of data in the notification or that the object perform only one notification. Once the client sets up an advisory connection, when the data in the referenced object changes, the server invokes the OnDataChange method of the IAdviseSink interface, which notifies the advisory sink and is passed to the object as a parameter in the DAdvise method. The IAdviseSink interface will be described in more detail below. The DAdvise method is defined in Code Table No. 10.
The pformatetc parameter of the DAdvise method contains a pointer to a FORMATETC structure which indicates the preferences of the client for the data returned in the notification. The grfAdvf parameter contains a value indicating the choices of the client for the composition of the notification and how the notification will be performed. Acceptable values for the grfAdvf parameter include: ADVF.sub.-- NODATA, ADVF.sub.-- ONLYONCE, ADVF.sub.-- PRIMEFIRST, and ADVF.sub.-- DATAONSTOP. The ADVF.sub.-- NODATA value in the grfAdvf parameter indicates not to return the changed data in the notification. A value of ADVF.sub.-- ONLYONCE indicates that the advisory connection will be disconnected after one notification. A value of ADVF.sub.-- PRIMEFIRST indicates that the server will send an additional notification to the advisory sink when the referenced data in the object first becomes available. A value of ADVF.sub.-- DATAONSTOP indicates that an additional notification will be sent to the advisory sink upon the shutdown of the server. Also, the additional notification will contain the data that has changed. The values for the grfAdvf parameter are defined in terms of bits, thus, any combination of the values may be "ORed" together. One combination in particular, ADVF.sub.-- ONLYONCE ORed with ADVF.sub.-- PRIMEFIRST, allows a client to receive data from a server without having to wait for the data to become available (i.e., the client will receive the data at a later time). Although only one combination of the values for the grfAdvf parameter is described, one skilled in the art will recognize that other combinations of the values for the grfAdvf parameter provide useful functionality.
The pAdvSink parameter is a pointer to an IAdviseSink interface. The IAdviseSink interface contains a method defined by the client ("OnDataChange"). The OnDataChange method has two parameters. The first parameter to the OnDataChange method is a pointer to a FORMATETC structure indicating the preferences of the client for the data in the notification. The second parameter to the OnDataChange method is a pointer to a medium to be used for transferring the notification.
The pdwConnection is a handle to the advisory connection returned to the client upon successful completion of the DAdvise method. The advisory connection handle is used by the client to uniquely identify an advisory connection. The return.sub.-- value parameter of the DAdvise method indicates a successful or unsuccessful creation of an advisory connection.
The DUnadvise method in the IDataObject interface provides for disconnecting an advisory connection that was set up using the DAdvise method. The DUnadvise method is defined in Code Table No. 11.
The dwConnection parameter of the DUnadvise method is a handle to the advisory connection that the client wants disconnected. The advisory connection handle was returned to the client upon a successful completion of the DAdvise method. The return.sub.-- value parameter indicates whether the advisory connection was successfully disconnected.
The EnumDAdvise method of the IDataObject interface allows a client to enumerate all of the advisory connections currently on an object. The EnumDAdvise method is defined in Code Table No. 12.
The ppenumAdvise parameter for the EnumDAdvise method is a pointer to a pointer to a list of structures containing connection information for all connections on an object. The information contained in each structure includes the pformatetc, grfAdvf, dwConnection, and pAdvSink parameters that were passed to the server upon creation of the advisory connection through the DAdvise method. The return value of the EnumDAdvise is a value indicating a successful or unsuccessful completion of the EnumDAdvise method.
FIG. 9 depicts a flowchart of the steps performed for an advisory connection. In order to create an advisory connection, the client calls the DAdvise method of the IDataObject interface. After the advisory connection has been created, the server waits for the data in the object to change. Once the data in the object changes, the server sends a notification to the advisory sink by invoking the OnDataChange method of the IAdviseSink interface. The client first calls the DAdvise method of the IDataObject interface specifying the appropriate parameters (step 902). By invoking the DAdvise method, an advisory connection is established with the object. Next, the server determines if the data has changed (step 904). If the data has not changed, the server determines if the advisory connection has been disconnected (step 906). If the advisory connection has been disconnected, processing ends. However, if the advisory connection has not been disconnected, the server returns to step 904. If the data in the object has changed, processing continues to step 908, wherein the server determines the advisory sink to notify (step 908). The server determines the advisory sink to notify for an object by accessing a registry which contains information regarding all advisory connections on all objects in the server. Next, the server determines the preferences of the client for the notification by accessing the registry (step 910). After determining the preferences of the client, the server invokes the OnDataChange method in the IAdviseSink interface that was passed into the object when the client called the DAdvise method in the IDataObject interface (step 912). Invocation of the OnDataChange method in the IAdviseSink interface sends the notification to the advisory sink. After the notification has been sent to the advisory sink, the server continues to wait for the data to change.
FIGS. 10A and 10B depict a flowchart of the steps performed by a client performing data transfer utilizing UDT of the preferred embodiment of the present invention. The client first calls the QueryInterface method of the IUnknown interface in order to receive a pointer to the IDataObject interface for an object (step 1002). After receiving the pointer to the IDataObject interface, the client may invoke the methods of the IDataObject interface directly and, thus, transfer data utilizing UDT. As part of the UDT-related processing of the client, the client may decide to receive data from the object. However, before receiving data from the object, the client has a choice of whether to enumerate the available preferences for the data in the object (step 1004), determine whether specific preferences are supported by the server (step 1008), or query the server whether a second request for data would yield the same data as a previous request with different preferences (step 1012). If the client determines to enumerate the available preferences for the data, the client invokes the EnumFormatEtc method of the IDataObject interface (step 1006). If the client determines to query the server whether specific preferences are supported, the client invokes the QueryGetData method of the IDataObject interface (step 1010). If the client determines to query the server whether a second request for data would yield the same data as a previous request with different preferences, the client invokes the GetCanonicalFormatEtc method of the IDataObject interface (step 1014).
When the client is ready to receive the data, the client may choose to transfer the data over a specific medium (step 1016), or the client may choose to request the data so that the server can pick which medium to transfer the data over (step 1020). If the client determines to transfer the data over a specific medium, the client invokes the GetDataHere method of the IDataObject interface (step 1018). If the client decides to allow the server to pick the medium used for transferring the data, the client invokes the GetData method of the IDataObject interface (step 1022).
At some point during the processing of the client, the client may determine to send data to the object (step 1024 in FIG. 10B). When the client determines to send data to the object, the client invokes the SetData method of the IDataObject interface (step 1026). Instead of, or in addition to sending and receiving data from the object, the client may decide to perform processing associated with advisory connections. If the client determines to perform processing associated with advisory connections, the client may choose to set up an advisory connection (step 1028), disconnect an advisory connection (step 1032), or enumerate all advisory connections on the object (step 1036). If the client chooses to set up an advisory connection, the client invokes the DAdvise method of the IDataObject interface (step 1030). If the client chooses to disconnect an advisory connection, the client invokes the DUnadvise method of the IDataObject interface (step 1034). If, however, the client decides to enumerate all advisory connections on an object, the client invokes the EnumDAdvise method of the IDataObject interface (step 1038).
After invoking one method of the IDataObject interface, the client may determine to perform more UDT-related processing (step 1040). If the client determines to perform more UDT-related processing, the client continues to step 1004 wherein the client may invoke another method of the IDataObject interface. However, if the client determines not to perform more UDT-related processing, UDT-related processing ends.
Following is a description of five applications of data transfer functionality utilizing UDT of the preferred embodiment of the present invention. The five applications utilizing UDT include: cut-and-paste, drag-and-drop, real time data transfer, custom marshalling and programmatic transfer. FIG. 11 depicts a block diagram of a cut-and-paste application utilizing UDT of the preferred embodiment. The computer 500 contains a graphic device 1112, a memory 504 and a permanent storage device 506. The graphic device contains a GDI object 1110. The memory of the computer system 504 contains a data source 1102, a clipboard 1104, global memory 1122 and a data sink 1106. The data source 1102 contains an object 1108. The permanent storage device 506 contains a file 1114, a metafile 1116, a stream file 1118 and a storage object 1120. In performing a cut-and-paste application, when the user performs a cut operation, the data contained in the object 1108 is not copied to the clipboard 1104 like in prior methods. Instead, UDT is invoked and a reference to the object 1108 (a pointer to the IDataObject interface) is copied to the clipboard 1104. After the user selects the paste operation, the data sink 1106 locates the pointer to the IDataObject interface in the clipboard 1104, and uses the IDataObject interface to copy the data from the object 1108 to the data sink 1106 through a medium 1110, 1114, 1116, 1118, 1120 and 1122. Since the cut-and-paste of the preferred embodiment uses a pointer to the IDataObject interface instead of copying the data, the format conversion of the data does not occur until the data sink 1106 requests the data through the IDataObject interface. This provides the data sink 1106 with the ability to delay the conversion of the data ("delayed rendering"). Also, when the data sink 1106 needs multiple formats of the data, the data sink 1106 may select one format, use the format and then request another format. This allows the data sink 1106 to start processing the data without having to wait for all of the format conversions to take place. Delayed rendering, thus, allows for a more efficient use of the data sink 1106 and reduces the total system performance degradation associated with format conversion.
FIG. 12 depicts a flowchart of the steps performed by a cut-and-paste application utilizing UDT of the preferred embodiment. First, the data source 1102 places a pointer to the IDataObject interface onto the clipboard 1104 (step 1202). Next, upon invocation of the paste operation, the data sink 1106 accesses the clipboard 1104 to retrieve the pointer to the IDataObject interface (step 1204). After receiving the pointer to the IDataObject interface, the data sink 1106 can access the object 1108 directly. The data sink 1106 then uses the EnumFormatEtc method of the IDataObject interface to enumerate the formats of the requested data so that the data sink 1106 may choose a format acceptable for the needs of the data sink 1106 (step 1206). For example, if the data sink 1106 can accept more than one format, enumerating the available formats allows the data sink 1106 to determine which format would be best suited for the purposes of the data sink and, perhaps, the easiest to process. After enumerating the available formats of the data, the data sink 1106 selects a format and invokes the GetData method of the IDataObject interface to transfer the data from the data source 1102, through a medium 1110, 1114,1116, 1118, 1120, 1122, to the data sink 1106 and perform the appropriate format conversion. In computers which use OLE, the data source 1102 calls the OleSetClipboard function to place an IDataObject reference onto the clipboard 1104 and the data sink 1106 calls the OleGetClipboard function to retrieve the pointer to the IDataObject interface from the clipboard 1104.
FIG. 13 depicts a block diagram of a drag-and-drop application utilizing UDT of the preferred embodiment. The application uses a graphic device 1112, memory 504 and a permanent storage device 506. The graphic device 1112 contains a graphic device interface object (GDI) 1110. The memory 504 contains a data source 1102, global memory 1122, a window manager 1314 and a data sink 1106. The data source 1102 contains an object 1108. The permanent storage device 506 contains a file 1114, a metafile 1116, a stream file 1118 and a storage object 1120. In performing a drag-and-drop application, when the user drops selected data into the data sink 1106, the window manager 1314 establishes a connection between the data sink 1106 and the object 1108. The window manager 1314 establishes the connection between the object 1108 and the data sink 1106 by passing a pointer to the IDataObject interface to the data sink 1106. By receiving a pointer to the IDataObject interface, the data sink 1106 can access the object 1108 directly. After receiving the pointer to the IDataObject interface, the data sink 1106 uses the GetData method of the IDataObject interface to transfer the data in the object 1108 from the data source 1102 through a medium 1110, 1114,1116, 1118,1120, 1122 and to the data sink 1106.
FIG. 14 depicts a flowchart of the steps performed by a drag-and-drop application utilizing UDT of the preferred embodiment. First, the data sink 1106 registers with the window manager 1314. Registration signifies that the data sink 1106 is available for drops (step 1402). In computer systems wherein a process may have multiple windows, the data sink 1106 specifies which windows of the data sink 1106 are available for drops. In addition, when registering with the window manager 1314, the data sink 1106 specifies callback routines to be invoked upon a drop. A callback routine is a function invoked upon the occurrence of a specific event. Next, the data source 1102 invokes the window manager 1314 to perform the drag-and-drop operation (step 1404). After the drop occurs, the callback routine specified by the data sink 1106 at registration with the window manager 1314 is invoked by the window manager 1314 (step 1406). The window manager 1314 invokes the callback routine with a pointer to the IDataObject interface, and the callback routine uses the IDataObject interface pointer to call the EnumFormatEtc method in the IDataObject interface (step 1408). The callback routine then selects an acceptable format for receiving the data and invokes the GetData method in the IDataObject interface to receive the data (step 1410). In computers which use OLE, the data sink 1106 registers with the window manager 1314 by calling the RegisterDragDrop function and specifying the windows in which a drop is allowed and a Drop callback routine. Further, in a computer using OLE, the data source 1102 calls the DoDragDrop function to invoke the window manager 1314 to perform a drag-and-drop operation.
FIG. 15 depicts a diagram of a real time data transfer application utilizing UDT of the preferred embodiment. A real time data transfer application (XRT) is an application that receives real time data from a network and sends the real time data to an object. An example of an XRT system is a system which receives real time stock quotes from the New York Stock Exchange and sends the real time stock quotes to an object so that spreadsheets with an advisory connection to that object are automatically updated. The XRT application uses a network 1504 and the memory of a computer 504. Within the memory 504 is a server 1502 and a client 1506. The server 1502 contains an object 1108. The client 1506 uses the real time data 1508 received from the object 1108 for processing. In order to receive the real time data 1508 of the object 1108, the client 1506 accesses the IDataObject interface through the IUnknown interface of the object 1108. After receiving a pointer to the IDataObject interface, the client 1506 invokes the DAdvise method of the IDataObject interface to create an advisory connection. Thus, when the object 1108 receives real time data 1508 from the network 1504, which updates data upon which the client 1506 has established an advisory connection, the server 1502 invokes the OnDataChange method of the IAdviseSink interface and informs the client 1506 of the new data.
FIG. 16 depicts a custom marshalling application utilizing UDT of the preferred embodiment. A custom marshalling application is an application which preprocesses data before the data is returned to a client over an advisory connection. The custom marshalling application operates in the memory 504 of a computer. The memory 504 contains a server 1502 and a client 1506. The server 1502 contains an object 1108 and a filtering mechanism 1604. The filtering mechanism 1604 is supplied by the client and performs some operation upon data contained within the object 1108. The operation that the filtering mechanism 1604 may perform includes calculations and selectivity. Therefore, the server 1502 invokes the filtering mechanism 1604 provided by the client 1506, and the client 1506 is notified of the change of some data in the object 1108. In order to perform custom marshalling, the client 1506 first accesses the IDataObject interface through the IUnknown interface of the object 1108. The client 1506 then invokes the DAdvise method of the IDataObject interface creating an advisory connection whereby the filtering mechanism 1604 is notified if data in the object 1108 changes. The server 1502 sends a notification to the filtering mechanism 1604 when data in the object 1108 changes by using the OnDataChange method in the IAdviseSink interface. The filtering mechanism 1604 then performs an operation on the received data and sends the resulting data to the client 1506.
FIG. 17 depicts a programmatic transfer application utilizing UDT of the preferred embodiment of the present invention. The programmatic transfer application provides a mechanism whereby developers may programmatically use UDT. The developer inputs commands into a script, and the script is executed by an engine that generates commands for UDT. After receiving the generated commands, UDT performs the received commands. The programmatic transfer mechanism 1702 and a computer program 1710 reside within the memory 504 of a computer system. The programmatic transfer mechanism 1702 contains a script 1708, an engine 1706 and the UDT 1704. The computer program 1710 contains an object 1712. The script 1708 is a batch file of commands understandable by the engine 1706. The engine 1706 is a computer program which reads the script 1708 and invokes commands understandable by the UDT 1704. The uniform data transfer mechanism 1704 may be used to communicate with an object 1710, other clients or servers. In order to use the programmatic transfer application 1702, a developer creates a script 1708 containing commands that the developer wishes to invoke. The engine 1706 then reads the script 1708, creates parameters from the received script commands and invokes the appropriate methods of UDT 1704. The programmatic transfer mechanism is a powerful tool that provides a developer with quick and easy access to UDT 1704. The developer has quick access because the developer only inputs commands to the script 1708 in order to invoke UDT 1704. Such quick and easy access to UDT 1704 provides a tool that developers may use to test computer programs which transfer data.
An alternative computer system for performing the programmatic transfer mechanism utilizing the preferred embodiment of the present invention is depicted in FIG. 18. The programmatic transfer mechanism 1802 and two computer programs 1804, 1806 reside within the memory 504 of a computer system. The programmatic transfer mechanism 1802 has a script 1808 containing commands and an engine 1810 which understands and invokes the commands of the script 1808. The computer program 1804 contains an object 1812 and the computer program 1806 contains UDT 1814 of the preferred embodiment. In the alternative programmatic transfer application, a developer inputs commands into the script 1808, and the commands are executed by the engine 1810. The executed commands retrieve a pointer to the IDataObject interface of the object 1812 and pass the pointer of the IDataObject interface to the computer program 1806. Once the computer program 1806 has the pointer to the IDataObject interface, the computer program 1806 then invokes UDT 1814 to transfer data contained within the object 1812.
While the present invention has been described with reference to a preferred embodiment thereof, those skilled in the art will note that various changes in form may be made without departing from the spirit and scope of the claimed invention as defined in the appended claims.
Claims
Certificate of Correction present
The claims shown below may not include correction changes. Use the corrected PDF for authoritative text.
We claim:
1. A method for transferring data between a source process and a destination process in a data processing system having a plurality of connection mechanisms for establishing logical connections between the source process and the destination process, the method comprising the steps of: providing to the source process and to the destination process a uniform data transfer module for transferring the data from the source process to the destination process; establishing a logical connection between the source process and the destination process utilizing one of the plurality of connection mechanisms; and transferring the data from the source process to the destination process utilizing the uniform data transfer module, wherein the uniform data transfer module transfers the data in a manner that is independent of the connection mechanism used to establish the logical connection such that the uniform data transfer module operates in the same manner to transfer the data regardless of which of the plurality of connection mechanisms is used to establish the logical connection.
2. The method of claim 1 wherein the data processing system has only one uniform data transfer module.
3. The method of claim 1 wherein the source process resides within an address space, and wherein the step of providing to the source process and to the destination process includes linking the uniform data transfer module into the address space.
4. The method of claim 1 wherein the data processing system is an object based data processing system having a plurality of objects, one of the objects being a source object that is part of the source process and one of the objects being a destination object that is part of the destination process, wherein the step of establishing a logical connection includes establishing the logical connection between the source object and the destination object, and wherein the step of transferring the data includes transferring the data from the source object to the destination object.
5. The method of claim 1 wherein the source process contains a plurality of interfaces, one of the interfaces being a uniform data transfer interface having methods for invoking the uniform data transfer module and one of the interfaces being a connection interface having methods for establishing the logical connection between the source process and the destination process, wherein the step of establishing a logical connection includes invoking the methods of the connection interface by the destination process to establish the logical connection between the source process and the destination process, and wherein the step of transferring the data includes invoking the methods of the uniform data transfer interface by the destination process to transfer the data from the source process to the destination process.
6. The method of claim 1 wherein the data processing system performs a cut and paste operation and has a clipboard, wherein the source process has a data object with functions for transferring the data, and wherein the step of establishing a logical connection includes performing a cut and paste operation to establish the logical connection, wherein a reference to the data object is placed on the clipboard by the source process and retrieved from the clipboard by the destination process, and wherein the step of transferring the data includes invoking the functions of the data object to effect the transfer of the data.
7. The method of claim 1 wherein the data processing system is an object based data processing system operating with a plurality of objects and having a clipboard for storing references to data to be transferred in a data transfer operation, and wherein the step of establishing a logical connection includes placing a reference to an object onto the clipboard so that the data transfer operation may be performed on the object via the clipboard.
8. The method of claim 1 wherein the destination process specifies a format for the data and wherein the step of transferring the data includes converting the data into the format specified by the destination process.
9. The method of claim 8 wherein the data processing system has a plurality of devices, each of the devices utilizing data in an associated format, and wherein the step of converting the data includes specifying the format for the data utilized by one of the devices and converting the data to the specified format of the one device.
10. The method of claim 1 wherein the data processing system has a display and a window manager for managing windows on the display and for establishing a logical connection during a drag and drop operation on a screen element on the display, wherein the source process has a data object with functions for transferring the data, wherein the step of establishing a logical connection includes performing the drag and drop operation by the window manager on the screen element on the display such that the window manager passes a reference to the data object from the source process to the destination process and wherein the step of transferring the data includes invoking the functions of the data object by the destination process to effect the transfer of the data.
11. The method of claim 1 wherein the data processing system is connected to a network and the source process contains a real time data transfer mechanism for receiving real time data from the network, wherein the step of establishing a logical connection includes establishing an advisory connection such that when the source process receives the real time data, the source process sends the real time data to the destination process and wherein the step of transferring the data includes receiving the real time data by the source process and sending the real time data to the destination process.
12. The method of claim 1 wherein the data processing system contains a programmatic transfer mechanism that provides a programmatic interface to the uniform data transfer module, wherein the source process has a data object with functions for transferring the data, wherein the method includes the step of providing a script containing commands to the programmatic transfer mechanism, wherein the step of establishing a logical connection includes performing the commands within the script by the programmatic transfer mechanism such that a reference to the data object is passed from the source process to the destination process and wherein the step of transferring the data includes invoking the functions of the data object by the destination process to effect the transfer of the data.
13. The method of claim 1 wherein the data processing system contains a filtering mechanism for filtering the data according to a selection criteria so as to send only filtered portions of the data and for sending the filtered portions of the data to the destination process, and wherein the step of transferring the data includes filtering the data by the filtering mechanism according to the selection criteria.
14. The method of claim 1 wherein the data processing system has a plurality of computer programs and a plurality of media for transferring the data, and wherein the step of transferring the data includes the steps of selecting a medium among the media for transferring the data between the source process and the destination process and invoking the uniform data transfer module to transfer the data from the source process through the selected medium to the destination process.
15. The method of claim 1 wherein the data processing system has a plurality of computers, wherein the source process is on a first of the computers and the destination process is on a second of the computers, wherein the first computer and the second computer are connected by a communication component for transferring the data, and wherein the step of transferring the data includes transferring the data from the source process through the communication component and to the destination process.
16. The method of claim 1 wherein the data processing system has an advisory sink for receiving notifications from the source process when advisory data in the source process is modified, wherein the data of the source process includes the advisory data, wherein the step of transferring the data includes the steps of: establishing an advisory connection such that the destination process identifies the advisory data within the source process, wherein the advisory sink request notification upon the modification of the advisory data; and when the advisory data is modified, sending a notification from the source process to the advisory sink containing the modified data.
17. In a distributed system having a first software entity that is a source of a communication and a second software entity that is a destination of the communication, a communication mechanism comprising: a plurality of connection components for establishing connections between the source and the destination; and a data transfer component for receiving a data transfer request from the destination and for transferring data between the source and the destination responsive to the data transfer request after a connection has been established by one of the connection components, wherein the data transfer component transfers the data in a manner that is independent of the connection component used to establish the connection such that the data transfer component operates in the same manner to transfer the data regardless of which of the plurality of connection components is used to establish the connection, further comprising: a general transfer component for transferring the data from the source to the destination wherein the data transfer request specifies preferences for characteristics of the data and indicia of a plurality of transfer media and wherein the source selects one medium of the transfer media for transferring the data; a specific transfer component for transferring the data from the source to the destination wherein the data transfer request contains preferences for the characteristics of the data and a reference to the medium to be used for transferring the data; a query component for determining whether the data transfer request is supported by the source; a format component for determining the characteristics of the data transferred in response to the data transfer request, wherein the destination invokes the format component to determine if the characteristics of the data are suitable to the destination; a send component for sending the data from the destination to the source; a characteristic component for determining data characteristics supported by the source; and an advise component for establishing an advisory connection between the source and the destination, wherein the destination specifies advisory data within the source and an advisory sink to be notified when the advisory data is modified, the advisory sink being a software entity.
18. The distributed system of claim 17 further including an unadvise component for disconnecting the advisory connection between the source and the advisory sink.
19. The distributed system of claim 17 further including a list advise component for identifying advisory connections of the source to enable the modification of the identified advisory connections.
20. In a computer system having a memory containing a plurality of computer programs in a state of operation for performing applications of data transfer functionality, each of the computer programs having a plurality of connection components for establishing logical connections between the computer programs and each of the connection components invoked for one of the applications of data transfer functionality, a method for sending data from a first of the computer programs to a second of the computer programs, the method comprising the computer-implemented steps of: s selecting one of the plurality of connection components to perform a given one of the applications of data transfer functionality, wherein the data is transferred between the first computer program and the second computer program; invoking the selected connection component to establish a logical connection between the first computer program and the second computer program; providing to the first computer program and to the second computer program a uniform data transfer component for transferring the data between the first computer program and the second computer program and for utilization with all the applications of data transfer functionality; and invoking the uniform data transfer component to transfer the data between the first computer program and the second computer program, wherein the uniform data transfer component transfers the data in a manner that is independent of the connection component used to establish the logical connection such that the uniform data transfer component operates in the same manner to transfer the data regardless of which of the plurality of connection components is used to establish the logical connection.
21. The method of claim 20 wherein the first computer program contains an engine for executing a script containing commands for the uniform data transfer component, and wherein the step of invoking the uniform data transfer component includes receiving the script by the first compute program and executing the commands in the script by the engine to invoke the uniform data transfer component.
22. The method of claim 20 wherein the computer has a programmatic transfer component for sending commands to the first computer program and the second computer program, wherein the step of invoking the selected connection component includes sending the commands from the programmatic transfer component to the first computer program and to the second computer program, and invoking the selected connection component to establish the logical connection between the first computer program and the second computer program to perform one of the applications of data transfer functionality in response to receiving the commands, and wherein the step of invoking the uniform data transfer component includes invoking the uniform data transfer component with the commands to transfer the data between the first computer program and the second computer program in response to establishing the connection.
23. A method for transferring data from a source computer program to a destination computer program in a computer system, the method comprising the computer-implemented steps of: providing a data object for the source computer program, the data object having member functions for transferring the data from the source computer program to the destination computer program in a way that is independent of a mechanism for specifying that data is to be transferred from the source computer program to the destination computer program; passing a reference to the provided data object from the source computer program to the destination computer program to establish a connection between the source computer program and the destination computer program; and under control of the destination computer program, using the passed reference to invoke a member function of the data object to effect the transfer of the data from the source computer program to the destination computer program.
24. The method of claim 23 wherein the data object is an interface containing the member functions.
25. A method in a computer system for performing a data transfer operation that transfers data from a source to a destination, the computer system having a plurality of mechanisms for identifying the source and the destination of the data transfer operation, the method comprising the computer-implemented steps of: selecting one of the plurality of mechanisms; invoking the selected mechanism to identify the source and the destination of the data transfer operation and to send a reference to the data to be transferred from the source to the destination; and transferring the data from the source to the destination using the reference in a manner that is independent from the selected mechanism.
26. A method for performing a plurality of applications of data transfer functionality wherein data is transferred between a source computer program and a destination computer program in a computer system having a uniform data transfer component for transferring the data and for utilization with all of the applications of data transfer functionality, each application of data transfer functionality having an associated connection component for establishing a logical connection between the source computer program and the destination computer program, the method comprising the computer-implemented steps of: selecting a first of the connection components to perform a first of the applications of data transfer functionality; invoking the first connection component to establish a first logical connection between the source computer program and the destination computer program; invoking the uniform data transfer component to transfer a first portion of the data between the source computer program and the destination computer program after invoking the first connection component; selecting a second of the connection components to perform a second of the applications of data transfer functionality; invoking the second connection component to establish a second logical connection between the source computer program and the destination computer program; and invoking the uniform data transfer component to transfer a second portion of the data between the source computer program and the destination computer program after invoking the second connection component.
27. The method of claim 26 wherein the uniform data transfer component is an interface containing functions that transfer the data, wherein the step of invoking the first connection component includes the step of passing a reference to the interface to the destination computer program and wherein the step of invoking the uniform data transfer component to transfer a first portion of the data includes the step of invoking the functions of the interface by the destination computer program to effectuate the transfer of the first portion of the data from the source computer program to the destination computer program.
28. The method of claim 26 wherein the first application of data transfer functionality is a cut-and-paste operation wherein the first portion of the data is cut from the source computer program and pasted into the destination computer program and wherein the second application of data transfer functionality is a drag-and-drop operation wherein the second portion of the data is selected in the source computer program, dragged to the destination computer program and dropped into the destination computer program.
29. A method for transferring data from a source computer program to a destination computer program in a computer system having a plurality of applications of data transfer functionality, the method comprising the computer-implemented steps of: invoking one of the plurality of applications of data transfer functionality such that the transfer of the data is initiated; and transferring the data in an application-independent manner from the source computer program to the destination computer program such that the data is transferred in the same manner regardless of which of the plurality of applications of data transfer functionality is selected.
30. A method for transferring data from a source computer program to a destination computer program in a computer system, the source computer program performing a plurality of applications of data transfer functionality and having an interface containing functions which effectuate the transfer of the data, the method comprising the computer-implemented steps performed by the source computer program of: for at least two of the plurality of applications of data transfer functionality; sending a reference to the interface to the destination computer program; receiving an indication of an invocation of one of the functions of the interface via the sent reference; and transferring the data from the source computer program to the destination computer program in response to receiving the indication in a manner that is the same for each application of data transfer functionality.
31. The method of claim 30 wherein each of the plurality of applications of data transfer functionality has an associated connection mechanism for establishing a logical connection between the source computer program and the destination computer program, and wherein the step of sending a reference includes the step of invoking the connection mechanism associated with the application of data transfer functionality such that the connection mechanism passes the reference to the destination computer program.
32. The method of claim 30 further including the steps of: before sending the reference, providing a dynamically linked library that contains the interface to the computer system; and linking the dynamically linked library into the source computer program.
33. A method for transferring data from a source computer program to a destination computer program in a computer system, the source computer program and the destination computer program performing a plurality of applications of data transfer functionality, the source computer program having an interface containing functions which effectuate the transfer of the data, the method comprising the computer-implemented steps performed by the destination computer program of: for at least two of the plurality of applications of data transfer functionality, receiving a reference to the interface from the source computer program; invoking one of the functions of the interface via the received reference; and receiving the data from the source computer program in response to invoking one of the functions in a manner that is the same for each application of the data transfer functionality.
34. The method of claim 33 wherein each of the plurality of applications of data transfer functionality has an associated connection mechanism for establishing a logical connection between the source computer program and the destination computer program, and wherein the step of receiving a reference includes the step of receiving the reference via the connection mechanism associated with the application of data transfer functionality.
35. The method of claim 33 wherein the destination computer program lacks instructions for transferring the data from the source computer program to the destination computer program.
36. A computer-readable memory device that contains: an interface data structure comprising a plurality of entries, the interface data structure for use in transferring data from a source application program to a destination application program, the interface data structure being provided to the source application program after which the source application program provides a reference to the interface data structure to the destination application program whereupon the destination application program accesses at least one entry of the interface data structure via the reference to transfer the data, each entry comprising: a function that effectuates the transfer of the data from the source application program to the destination application program in a manner that is independent of a mechanism used to select the source application program and the destination application program.
37. The computer-readable memory device of claim 36 wherein the function in one of the entries transfers the data from the source application program to the destination application program, the function having parameters, wherein a first of the parameters is provided by the destination application program that specifies preferences for characteristics of the data and that specifies an indicia of a plurality of transfer media wherein the source application program selects one medium of the transfer media to be used for transferring the data and returns an indication of the selected medium to the destination application program in a second of the parameters.
38. The computer-readable memory device of claim 36 wherein the function in one of the entries transfers the data from the source application program to the destination application program, the function having parameters provided by the destination application program, a first of the parameters specifying preferences for the characteristics of the data and a second of the parameters specifying a reference to a medium to be used for transferring the data.
39. The computer-readable memory device of claim 36 wherein the function in one of the entries has a parameter provided by the destination application program that specifies preferences for the characteristics of the data and that specifies a medium to be used for transferring the data, and wherein the function returns an indication to the destination application program of whether the source application program can transfer the data in accordance with the specified preferences and specified medium.
40. The computer-readable memory device of claim 36 wherein the function in one of the entries has a first parameter provided by the destination application program that specifies requested preferences for the characteristics of the data and that specifies a requested medium to be used for transferring the data, and a second parameter returned to the destination application program that specifies returned preferences for the characteristics of the data to be returned by the source application program based on the requested preferences and that specifies a returned medium to be used for transferring the data by the source application program based on the requested medium.
41. The computer-readable memory device of claim 36 wherein the function in one of the entries sends second data from the destination application program to the source application program.
42. The computer-readable memory device of claim 36 wherein the function in one of the entries determines data characteristics supported by the source application program.
43. The computer-readable memory device of claim 36 wherein the function in one of the entries establishes an advisory connection between the source application program and the destination application program such that the destination application program specifies advisory data within the source application program and an advisory sink to be notified when the advisory data is modified, the advisory sink being a software entity.
44. The computer-readable memory device of claim 43 wherein the function in one of the entries terminates the established advisory connection.
45. The computer-readable memory device of claim 43 wherein the function in one of the entries returns an indication of all established advisory connections.
46. A computer-readable medium whose contents cause a data processing system to transfer data between a source process and a destination process, the data processing system having a plurality of connection mechanisms for establishing logical connections between the source process and the destination process, by performing the steps of: providing to the source process and to the destination process a uniform data transfer module for transferring the data from the source process to the destination process; establishing a logical connection between the source process and the destination process utilizing one of the plurality of connection mechanisms; and transferring the data from the source process to the destination process utilizing the uniform data transfer module, wherein the uniform data transfer module transfers the data in a manner that is independent of the connection mechanism used to establish the logical connection such that the uniform data transfer module operates in the same manner to transfer the data regardless of which of the plurality of connection mechanisms is used to establish the logical connection.
47. A computer-readable medium whose contents cause a computer system having a memory containing a plurality of computer programs in a state of operation to perform applications of data transfer functionality, each of the computer programs having a plurality of connection components for establishing logical connections between the computer programs and each of the connection components invoked for one of the applications of data transfer functionality, a method for sending data from a first of the computer programs to a second of the computer programs, by performing the steps of: selecting one of the plurality of connection components to perform a given one of the applications of data transfer functionality, wherein the data is transferred between the first computer program and the second computer program; invoking the selected connection component to establish a logical connection between the first computer program and the second computer program; providing to the first computer program and to the second computer program a uniform data transfer component for transferring the data between the first computer program and the second computer program and for utilization with all the applications of data transfer functionality; and invoking the uniform data transfer component to transfer the data between the first computer program and the second computer program, wherein the uniform data transfer component transfers the data in a manner that is independent of the connection component used to establish the logical connection such that the uniform data transfer component operates in the same manner to transfer the data regardless of which of the plurality of connection components is used to establish the logical connection.
48. A computer-readable medium whose contents cause a computer system to perform a plurality of applications of data transfer functionality wherein data is transferred between a source computer program and a destination computer program in the computer system, the computer system having a uniform data transfer component for transferring the data and for utilization with all of the applications of data transfer functionality, each application of data transfer functionality having an associated connection component for establishing a logical connection between the source computer program and the destination computer program, by performing the steps of: selecting a first of the connection components to perform a first of the applications of data transfer functionality; invoking the first connection component to establish a first logical connection between the source computer program and the destination computer program; invoking the uniform data transfer component to transfer a first portion of the data between the source computer program and the destination computer program after invoking the first connection component; selecting a second of the connection components to perform a second of the applications of data transfer functionality; invoking the second connection component to establish a second logical connection between the source computer program and the destination computer program; and invoking the uniform data transfer component to transfer a second portion of the data between the source computer program and the destination computer program after invoking the second connection component.
49. A computer-readable medium whose contents cause data to be transferred from a source computer program to a destination computer program in a computer system having a plurality of applications of data transfer functionality wherein each application initiates the transfer of the data, by performing the steps of: selecting and invoking one of the plurality of applications of data transfer functionality such that the transfer of the data is initiated; and transferring the data in an application-independent manner from the source computer program to the destination computer program such that the data is transferred in the same manner regardless of which of the plurality of applications of data transfer functionality is selected.
50. A computer-readable medium whose contents cause data to be transferred from a source computer program to a destination computer program in a computer system, the source computer program performing a plurality of applications of data transfer functionality and having an interface containing functions which effectuate the transfer of the data, by performing the steps of: under the control of the source computer program, for each of the plurality of applications of data transfer functionality, sending a reference to the interface to the destination computer program; receiving an indication of an invocation of one of the functions of the interface via the sent reference; and transferring the data from the source computer program to the destination computer program in response to receiving the indication in a manner that is the same for each application of data transfer functionality.
51. A computer-readable medium whose contents cause data to be transferred from a source computer program to a destination computer program in a computer system, the source computer program and the destination computer program performing a plurality of applications of data transfer functionality, the source computer program having an interface containing functions which effectuate the transfer of the data, by performing the steps of: under the control of the destination computer program, for each of the plurality of applications of data transfer functionality, receiving a reference to the interface from the source computer program; invoking one of the functions of the interface via the received reference; and receiving the data from the source computer program in response to invoking one of the functions in a manner that is the same for each application of the data transfer functionality.
Patent Citations (7)
Non-Patent Literature (11)
- Microsoft Windows Software Development Kit: Programmer's Reference, vol. 1: Overview, Microsoft Corporation, 1992, pp. 206-210, 211-212.
- Microsoft Windows Software Development Kit: Programmer's Reference, vol. 2: Functions, Microsoft Corporation, 1992, pp. 668, 670-672, 679-680, 685-686, 688-689, 695-698, 712-713, 722.
- Microsoft Windows Software Development Kit, vol. 1, Version 3.0 for the MS-DOS and PC-DOS Operating Systems, Microsoft Corporation, 1990, pp. 1-58, 1-59, 4-28, 4-29, 4-110, 4-111, 4-116, 4-117, 4-156, 4-157, 4-158, 4-159, 4-264, 4-265, 4-320, 4-321, 4-346, 4-347, 4-368, 4-369, 4-370, 4-371, 4-372, 4-373, 6-98, 6-99.
- Microsoft Windows Software Development Kit, vol. 2, Version 3.0 for the MS-DOS and PC-DOS Operating Systems, Microsoft Corporation, 1990, pp. 9-5, 9-6, Chapter 15.
- Microsoft Windows Software Development Kit, Guide to Programming, Version 3.0 for the MS-DOS and PC-DOS Operating Systems, Microsoft Corporation, 1990, Chapters 13 and 22.
- Technical Introduction to the Macintosh Family, Apple Computer, Inc., Addison-Wesley Publishing Company, Inc., Menlo Park, California, 1987, pp. 63-66.
- Garfinkel, S., and Michael K. Mahoney, NeXTSTEP Programming: Step One: Object-Oriented Applications, Springer-Verlag, New York, 1993, pp. 511-531.
- Carr, R., and Dan Shafer, The Power of PenPoint, Addison-Wesley Publishing Company, Inc., Menlo Park, California, 1991, pp. 1-19, 129-151.
- Inside Macintosh, vol. 1, Apple Computer, Inc., Addison-Wesley Publishing Company, Inc., Menlo Park, California, 1985, pp. 451-464.
- Petzold, C., Programming Windows, Microsoft Press, Redmond, Washington, 1990, pp. 777-807.
- An Introduction to operating Systems, by Harvey M. Deitel, Addison-Wesley Pub. Co., Copyright 1990.