Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1997-06-06
2001-07-17
Hafiz, Tariq R. (Department: 2762)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000, C717S152000
Reexamination Certificate
active
06263492
ABSTRACT:
FIELD OF INVENTION
The present invention relates to the design of object-oriented computer software. More particularly it relates to the componentization and optimization of run-time objects created with object designers.
BACKGROUND AND SUMMARY OF THE INVENTION
Object oriented programming is used to design computer software that is easy to create, cost effective to modify, and reusable. Object oriented programming objects are pieces of computer software that include object data and information and provide services through “object methods” (also called object operations or object functions). The object methods typically operate on private data such as instance data or object state data that the object owns. A collection of objects make up an “object class,” which is sometimes called an “object type.” An object class acts as a template that describes the behavior of sets of objects. An object's implementation is typically encapsulated, and is hidden from public view. Object private instance data can only be accessed by object methods private to the object class. Object public instance data is accessed through a public object interface.
The Component Object Model (COM) and Distributed Component Object Model (DCOM) are models used for object-oriented programming. The COM and DCOM specify how objects interact and communicate within a single application, a distributed application or between applications (e.g., client/server applications) by defining a set of standard interfaces. Object interfaces are groupings of semantically related functions through which a client application accesses the services of a server application.
Object Linking and Embedding (OLE), such as OLE Version 2 and ActiveX Controls by Microsoft Corporation of Redmond, Wash. are based in part on the Component Object Model. They allow the creation of objects which operate on object data through defined object interfaces, rather than operating on the applications responsible for the data. ActiveX controls are based in part on OLE technologies. An ActiveX control is an object with properties such as color, shape and event notifications (e.g., “someone has clicked on me”). OLE and ActiveX controls are known to those skilled in the art.
An object designer is a top-level software component that runs within a dedicated design environment. Object designers provide features which can be used and customized by developers to develop objects or classes of objects for use in their applications, components, etc. The Forms object class (i.e., graphical form .FRM) provided with the Visual Basic programming language by Microsoft Corporation is one type of object designer.
For example, the supplier of a large management information system (MIS) application might develop an object designer that contains forms and controls unique to its databases. Database programmers at customer sites can then use the designer to design local applications that access the database and perform specific query and update tasks.
As another example, a multimedia design package for object-oriented applications used on a computer network like the Internet or an intranet might include an object designer that allows developers to edit text and graphics. Using such a designer, a developer could create a “Happy Birthday” object that contains the text “Happy Birthday!”, a sound clip of a birthday song, and a graphical image of a cake, with graphical candles blazing.
An object designer manages the design-time aspects of an object by visually designing objects as well as managing the run-time aspects of the object it designs. The object designer creates and destroys windows (e.g., windows within one of the windowed operating systems by Microsoft Corporation), handles the user interaction, and controls the look and feel of the designer within the visual host environment. It also provides information about the objects in the designer and allows property browsers, wizards (e.g., help wizards), and other tools to manipulate the objects.
Using an object designer, developers can create and manipulate objects and modify the properties of these objects. The customizations become part of the data used at run-time in an executable application making use of these objects. In the current art, a run-time object which makes use of the objects are actually another instance of the object designer itself. Thus, the object designer is a monolithic object designer which must support both design-time and run-time behaviors. Also, the data used at run-time is the same data that is used at design-time when loading the object for further manipulation.
As is known in the art, an object designer class is used to create a new instance of a design-time object. Customizations and property changes made in the design-time object are saved in a storage medium for later use. When the customizations and property changes are saved, a developer can later make further modifications without keeping the design-time object loaded in memory. A new instance of the design-time object is created and re-initialized from the data saved in storage. At run-time, the object designer class is used to instantiate a run-time object using the data saved in storage which includes a design-time object.
Developers can also write code to further customize and manipulate the properties, methods, and events of the run-time objects they create. This customization code is not managed by the object designer, but rather is managed by the development environment itself.
There are several problems associated with an object designer class which implements both run-time objects and design-time objects. The design-time object and run-time object will often differ in functionality. For example, the design-time object displays a grid for laying out object controls, while the run-time object has no need for such functionality. As another example, the design-time object is visible (e.g., it is used to design an object with a user interface and contains components like grids, etc.), while the run-time object may be invisible (e.g., used to query a database) and not require a user interface during run-time. As a result, a library, such as a dynamic link library (.DLL) used to implement the object designer class is significantly larger than it needs to be since a large portion of the design-time functionality (e.g., the design-time user interface used to create the object) is not used at run-time. The presence of unnecessary design-time code in a library used at run-time significantly impacts the resources of a computer that the run-time object is executed on. The run-time object will require more time to load into memory and more time to execute since it contains design-time code which is not used at run-time.
Another problem associated with an object designer class which implements both run-time objects and design time objects is that an originating developer who distributes the object library (because it is required to create run-time objects) under some agreement (e.g., a license) is also distributing the design-time functionality. A receiving developer who receives the object designer can potentially create new run-time applications using the embedded design-time functionality of the object designer library. This use of the design-time objects might be beyond the scope of the distribution agreement intended by the originating developer who distributed the object. Thus, the originating developer could potentially lose revenue or other benefits that were negotiated under the original distribution agreement.
Yet another problem is that run-time objects created by the object designer have to be the same object class as the design-time objects. This is because the object designer is the object class implementing both the run-time objects and the design-time objects. This limits the number of object classes for which run-time objects can be created with object designers.
Yet another problem is that the data needed to instantiate run-time objects is saved in the same persistence (i.e., non-volatile) format as the design-time ob
Burd Gary S.
Carter Alan W.
Fraley Christopher Lee
Halcoussis Michael
Hodges C. Douglas
Hafiz Tariq R.
Ingberg Todd
Klarquist Sparkman Campbell & Leigh & Whinston, LLP
Microsoft Corporation
LandOfFree
Run time object layout model with object type that differs... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Run time object layout model with object type that differs..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Run time object layout model with object type that differs... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2561365