1
SYSTEM AND METHOD FOR TRANSFORMING AN XML FILE INTO AN ADD-IN FUNCTION FOR IMPLEMENTATION INTO A SPREADSHEET APPLICATION
5
STATEMENT OF RELATED PATENT
APPLICATION
This non-provisional patent application claims priority under 35 U.S.C. §119 to U.S. Provisional Patent Application 10 No. 60/792,480, titled System and Method for Transforming an XML File into an Add-In Function for Implementation Into a Spreadsheet Application, filed Apr. 17, 2006. This provisional application is hereby fully incorporated herein by reference. 15
FIELD OF THE INVENTION
The present invention relates to the field of computerimplemented spreadsheet applications. In particular, the 20 invention provides a computer-based system and method of converting XML to an interface definition language to define an interface in a COM server.
BACKGROUND OF THE INVENTION 25
Computerized spreadsheet applications, such as Microsoft Corporation's EXCEL software product have gained widespread use. Individuals and businesses routinely use computerized spreadsheets for a variety of purposes, such as account- 30 ing, finance, and investments.
Over the years, the functionality made available to users of these spreadsheet applications has grown significantly. Users of these applications are now able to implement functionality or import data embedded in areas outside the spreadsheet 35 application in order to satisfy the needs of the user. One objective of today's users is to implement analytical functionality stored in a Component Object Model ("COM") server from the spreadsheet application.
Unfortunately, current methods of implementing the func- 40 tionality in the COM server can be time and coding intensive. First, a user or developer is not able to call the COM server directly from the spreadsheet application. The developer is typically required to build an additional layer, or wrapper, around the COM server in order to translate the functionality 45 from the COM server to the spreadsheet application. Currently there are several conventional methods for building the additional layer to translate the functionality from the COM server to the spreadsheet application. One conventional method includes writing the COM server. Next, the developer 50 defines the interface of the COM server using standard computing toolsets provided by Microsoft Corporation. Next, the code for the function is implemented. Finally, the developer writes a dynamic link library defining attributes of the function. In addition, the developer will have to manually write the 55 mapping layer that translates the differences between the COM server and the spreadsheet application.
When writing the COM server, the developer will be required to define an interface to the COM server. The COM server typically includes one or more COM classes. Each 60 COM class can contain one or more methods. For each method associated with a COM class in the COM server, the developer wants to include a corresponding function to the add-in function.
Methods associated with each COM class are typically 65 complex to understand for the everyday user of the spreadsheet application. Each method typically includes documen
2
tation. The documentation provides information as to what an input will do in a method, what restrictions are placed on a method, under what conditions the method will respond, whether the method will converge, etc. The documentation needs to be stored in a place that is documented for COM servers, for users using the COM servers, and with add-in functions, for people using add-in functions, so that there is consistency between the COM server and the add-in server.
Problems arise because the toolsets provided for building COM servers are too basic. If a developer wants to add a method or argument to a COM server during development of the COM server, the developer has to made manual changes in several different places for each addition. For example, first, the developer will have to change the interface definition language ("IDL"). The Microsoft Interface Definition Language ("MIDL") is one example of an IDL. The MIDL is a standard way for defining COM interfaces. To change portions of the IDL the developer would need to modify some aspects of the implementation of the COM server.
In addition, the header file of the class definition and the class definition itself would have to be modified in order to change the definition of the function or add the definition of the function to the COM server. Furthermore, in the add-in, the developer would need to add a new function and write addition-specific code that translates the function from the spreadsheet to the COM server.
In view of the foregoing there is a need in the art for a method to allow a spreadsheet application user to define the interface between the spreadsheet application and the COM server independent of all places the interface is defined so that when implemented, the interface automatically inserts the information that a developer previously had to insert manually into each portion of the COM and add-in servers, so that a function in a COM server can be directly accessed from the spreadsheet application.
SUMMARY OF THE INVENTION
The XML conversion system provides methods and architecture for defining an interface between a spreadsheet application and a COM server independent of the areas that the interface is defined. In support of defining the interface, an add-in function defines the interface using extensible markup language ("XML"). An add-in function typically provides additional functionality to a spreadsheet application. Add-in functions can also be called plug-ins or add-ons. In one exemplary embodiment, add-in functions can be added to a spreadsheet application through the use of an add-in manager or wizard that provides users a step-by-step process for inserting the add-in or making it available to the spreadsheet application. In one exemplary embodiment, the XML file defines the interface for the add-in function.
One or more instructions within the add-in XML file can be analyzed by a COM server to determine if the add-in XML file contains instructions to expose an interface. If the add-in XML file contains instructions to expose an interface, the COM server can determine if an XML file for that interface exists in the COM server. The COM server may then begin building the add-in function by retrieving the function specifications from the interface that will be exposed. Each function specification can include the name of the function, the function type, data types of the function, a description of what the function can and cannot do, and one or more arguments.
The instruction in the XML file can then be analyzed to determine if it contains function qualifiers. Function qualifiers are typically instructions that can modify the function specification or modify the processing of the function specification. For example, function qualifiers can include instructions that rename the function specification. In addition, function qualifiers can include instructions to ignore the function specification and exclude it from the output of the add-in function. If the instruction contains function qualifiers for the 5 particular function specification, the function qualifiers can be applied to the function specification and the function specification can be converted to an intermediate function.
The intermediate function is typically a middle processing step between the function specification and the add-in func- 10 tion that includes a form for receiving information from the function specification, the interface and the instruction from the add-in XML file. Implementation specifiers can be added to the intermediate function by the COM server and can be located in the add-in XML file. The implementation specifier 15 typically provides an instruction in the add-in XML file to override the implementation type for an interface. In one exemplary embodiment implementation specifiers include, but are not limited to, "clone and modify," "create and define," "create and call," and "method call". Upon completion of the 20 addition of the implementation specifiers, the intermediate function is converted into an add-in function and sent to the spreadsheet application for processing in a manner similar to other add-in functions in the spreadsheet application.
25
BRIEF DESCRIPTION OF DRAWINGS
For a more complete understanding of exemplary embodiments of the present invention and the advantages thereof, reference is now made to the following description in con- 30 junction with the accompanying drawings in which:
FIG. 1 is a block diagram illustrating an exemplary operating environment for implementation of various embodiments of the present invention;
FIGS. 2 and 2A are flowcharts illustrating a process for 35 converting XML language to an interface definition language in accordance with an exemplary embodiment of the present invention;
FIG. 3 is a flowchart illustrating a process for transforming functions into intermediate functions in accordance with one 40 exemplary embodiment of the present invention;
FIG. 4 is a flowchart illustrating a process for applying an implementation specifier and transforming an intermediate function into an add-in function in accordance with one exemplary embodiment of the present invention; and 45
FIG. 5 is a flowchart illustrating a process for setting the implementation and return values in an add-in function in accordance with one exemplary embodiment of the present invention.
50
DETAILED DESCRIPTION OF THE
EXEMPLARY EMBODIMENTS
The present invention supports computer-implemented methods and architecture for defining an interface between a 55 spreadsheet application and a COM server independent of the areas that the interface is defined. Exemplary embodiments of the invention can be more readily understood by reference to the accompanying figures.
Although exemplary embodiments of the present invention 60 will be generally described in the context of a software module and an operating system running on a personal computer, those skilled in the art will recognize that the present invention can also be implemented in conjunction with other program modules for other types of computers. Furthermore, 65 those skilled in the art will recognize that the present invention may be implemented in a stand-alone or in a distributed
computing system environment. In a distributed computing environment, program modules may be physically located in different local and remote memory storage devices. Execution of the program modules may occur locally in a standalone manner or remotely in a client/server manner. Examples of such distributed computing environments include local area networks, enterprise-wide computer networks, and the global Internet.
The detailed description that follows is represented largely in terms of processes and symbolic representations of operations by conventional computer components, including processing units, memory storage devices, display devices, and input devices. These processes and operations may utilize conventional computer components in a distributed computing environment.
The processes and operations performed by the computer include the manipulation of signals by a processing unit or remote computer and the maintenance of these signals within data structures resident in one or more of the local or remote memory storage devices. Such data structures impose a physical organization upon the collection of data stored within a memory storage device and represents specific electrical and magnetic elements. These symbolic representations are the means used by those skilled in the art of computer programming and computer construction to most effectively convey teachings and discoveries to others skilled in the art.
Exemplary embodiments of the present invention include a computer program that embodies the functions described herein and illustrated in the appended flowcharts. However, it should be apparent that there could be many different ways of implementing the invention in computer programming, and the invention should not be construed as limited to any one set of computer program instructions. Furthermore, a skilled programmer would be able to write such a computer program to implement a disclosed embodiment of the present invention without difficulty based, for example, on the flowcharts and associated description of the application text. Therefore, disclosure of a particular set of program code instructions is not considered necessary for an adequate understanding of how to make and use the present invention. The inventive functionality of the computer program will be explained in more detail in the following description and is disclosed in conjunction with the remaining figures illustrating the program flow.
Referring now to the drawings in which like numerals represent like elements throughout the several figures, aspects of the present invention and an exemplary operating environment for the implementation of the present invention will be described.
FIG. 1 is a block diagram illustrating an XML conversion system 100 constructed in accordance with an exemplary embodiment of the present invention. The exemplary system 100 comprises a spreadsheet application 105, COM server source code 110, add-in source code 115, add-in code generator 119, classes and supported interfaces 125, and class implementations 145. The spreadsheet application 105 is communicably attached to the COM server source code 110, add-in code generator 119, interface XML file 120 and class implementations 145, however, those of ordinary skill in the art will recognize that the spreadsheet application 105 could also be communicably attached to these other elements via a distributed computer network. In one exemplary embodiment, the spreadsheet application 105 is Microsoft EXCEL, however other spreadsheet applications 105 may be substituted in the invention. The spreadsheet application 105 can include add-in source code 115 and an add-in XML file 117.
|
