Development System With Methods for Improved Visual Programming With Hierarchical Object Explorer

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

The present invention relates generally to information processing environments and, more particularly to creating programs for the storing, retrieving, and presenting information in a data processing system, such as a Database Management System.

Computers are a powerful tool for the acquisition and processing of information. Computerized databases can be regarded as a kind of electronic filing cabinet or repository for collecting computerized data files; they are particularly adept at processing vast amounts of information quickly. As such, these systems serve to maintain information in database files or tables and make that information available on demand. Of these systems, ones which are of particular interest to the present invention are Relational Database Management Systems (RDBMSs).

The concept of relational databases is perhaps best introduced by reviewing the problems surrounding traditional or non-relational systems. In a traditional database system, the task of retrieving information of interest (i.e., answering a "database query") is left to the user; that is, the user must give detailed instructions to the system on exactly how the desired result is to be obtained.

Consider the example of a simple query: "Who are the teachers of student John Smith?" In a traditional system, several explicit instructions are required before the query can be answered. One instruction, for instance, is typically to instruct the system to allocate sections in memory for data to be read from a storage disk. Another command may tell the system which disk files to open and read into the allocated memory for processing. Still other commands may specify particular search strategies, such as use of specific indexes, for speeding up the result of the query. And still even further commands may be needed for specifying explicit links between two or more files so that their data may be combined. Thus, instead of just telling the system "what" is desired (i.e., the desired data result as expressed in a query expression), one must specify internal procedures (i.e., the "how") for obtaining the data. Even for a simple query, such as that above, the task is complex, tedious, and error-prone.

From the user's perspective, such details--ones directed to the physical implementation--are completely irrelevant; the user is interested only in the result. Thus, the lack of separation of logical operations from the physical representation of the data (i.e., how it is internally stored and accessed by the system) in traditional systems burdens users with unnecessary complexity. Moreover, as traditional database products employ proprietary data access procedures, knowledge of one product is not necessarily helpful in use of another. And where database systems differ, their practitioners cannot effectively communicate with one another.

In 1970, Dr. E. F. Codd invented the "relational model", a prescription for how a DBMS should operate. The relational model provides a foundation for representing and manipulating data, that is, a way of looking at data. The model includes three basic components: structure, integrity, and manipulation. Each will be described in turn.

The first of these, structure, is how data should be presented to users. A database management system is defined as "relational" when it is able to support a relational view of data. This means that data which a user can access and the operators which the user can use to operate upon that data are themselves relational. Data are organized as relations in a mathematical sense, with operators existing to accept relations as input and produce relations as output. Relations are perhaps best interpreted by users as tables, composed of rows (tuples) and columns (attributes).

Ideally, data in a relational system is perceived by users as tables and nothing but tables. This precludes the user from seeing explicit connections or links between tables, or having to traverse between tables on the basis of such links. It also precludes user-visible indexes on fields and, in fact, precludes users from seeing anything that smacks of the physical storage implementation. Thus, tables are a logical abstraction of what is physically stored.

The integrity aspect, on the other hand, dictates that every relation (i.e., table) should have a unique, primary key to identify table entries or rows. The integrity of the data for the user is of course crucial. If accuracy and consistency of the data cannot be achieved, then the data may not be relied upon for decision-making purposes.

Data manipulation, the last component, may be thought of as cut-and-paste operators for tables. Data manipulation is of course the purpose for which databases exist in the first place. The superiority of manipulating tables relationally (i.e., as a whole, or sets of rows) is substantial. Users can combine data in various tables logically by matching values in common columns, without having to specify any internal details or the order in which tables are accessed; this provides users with a conceptual view of the database that is removed from the hardware level. Non-relational DBMSs, in contrast, require complex programming skills that form an inherently unreliable means to interact with databases.

The general construction and operation of a database management system is known in the art. See e.g., Date, C., An Introduction to Database Systems, Volumes I and II, Addison Wesley, 1990; the disclosures of which are hereby incorporated by reference.

Today, relational systems are everywhere--commonly seen operating in corporate, government, academic settings, and other shared environments. However, the programming effort required to build and maintain RDBMS applications has proved to be a major stumbling block to the industry, especially as the need for GUIs (graphical user interfaces) has grown. GUIs are essentially "user-centered," meaning that the user, not the program, "directs the action" and establishes an appropriate data-model and event-model for his or her needs. GUIs demand an event-driven paradigm whereby programs respond to asynchronous user actions, rather than having the user react sequentially to choices offered by the program.

Traditional RDBMS programming methods have followed the program-driven (procedural) paradigm, presenting the user with a linear hierarchy of pre-determined menus. Thus, prior-art approaches to programming relational database applications include diverse procedural languages, such as dBASE III.RTM., whereby separate programs are written for linear, step-by-step solutions to particular data-retrieval and manipulation problems. The user can custom-design tables and reports but is forced to follow the sequential event-model imposed by the application.

Another problem posed by traditional RDBMS programming languages is the difficulty of reusing existing code for similar applications. The elements in the code that define data structures and those that manipulate the data are often spread arbitrarily throughout the program. This makes it difficult both to maintain programs and to isolate code segments that might prove reusable elsewhere.

A system of the present invention includes a relational database management system (RDBMS), where information is maintained in one or more database tables for easy, efficient storage and retrieval. The system provides an object-based, interactive visual-programming language accessible via a graphical user interface (GUI).

The system provides "visual inheritance" methods for simplifying programming tasks. Specifically, the user places screen objects (e.g., boxes, screen buttons, tables objects, and the like) on an on-screen window or "form," visually attaches selected "properties" and "methods" to the screen objects, and then establishes an "event model" that dictates how and when these properties and methods will be invoked. An object inherits (derives) properties and methods from other (parent) objects via visual "containership." A screen object visually constructed inside another object, such as a button drawn within a box, automatically inherits (i.e., has access to) the methods associated with the containing box. In turn, the box may be contained in some larger object (a window, say), and so on, until the outermost containing form is reached. Thus, each object in the containership hierarchy inherits progressively from the containing environment. If desired, the programmer has the option to "override" an inherited property or method for any particular object. In this manner, the writing of large, linear, procedural programs is replaced by object-based visual programming which is more interactive and intuitive.

To further simplify a user's task of developing an application, the system provides objects with appropriate built-in "default" properties and methods; explicit programming is needed only when an object is desired to be further customized. For example, button objects "know" that a "mouse click" event, by default, should call for the on-screen appearance of the button to temporarily change--to appear as if the button is being depressed. In many situations, the default (built-in) behavior of an object will satisfy the needs of the application with little or no customization.

The system also provides an object-based visual programming language which simplifies event-driven programming by non-experts via direct manipulation of visual objects on the screen. For instance, additional application-dependent actions may be added to an application by "attaching" custom code to desired objects. The object-based visual programming language includes a syntax optimized for interacting with the properties and methods of system objects.

Further, the present invention offers special windows that display, on demand, all or part of an application's containership hierarchy. Specifically, a family tree or "object tree" of selected objects is provided as a readily understandable diagram: named boxes that are connected like the corporative organization charts familiar to the user. The programmer can "browse" through these tree charts by selecting boxes of interest to invoke lists of their properties and methods.

As another aspect of the present invention, the system increases code reusability by providing a facility for cutting and pasting objects while preserving any attached properties and methods. Form design and similar objects are "bound" to their properties and methods as well as to other objects (including other forms, perhaps) that they contain. A screen button, for instance, not only comprises the on-screen appearance of a button but also encapsulates various properties and methods attached to the button. This "encapsulation" allows the entire functionality and appearance of an object (or a group of objects) to be quickly transferred or "cloned" (e.g., to another application) using common clipboard techniques, such as cut, copy, and paste--techniques usually associated with cutting and pasting data, not live objects. Having copied an object, the user can edit its properties and/or methods to fit the needs of its new destination. Or the pasted object may simply inherit new behavior by virture of its new containership context. In this manner, a collection of reusable objects or "clip objects" may be readily constructed for use in a variety of target applications.

In an alternative embodiment of the present invention, the object inspector and object tree hierarchy are collapsed into a single UI (user interface) element--an "Object Explorer" of the present invention. The Object Explorer avoids a disadvantage of first embodiment where a user is required to switch back and forth between an inspector/property sheet user interface element and an object tree user interface element. Additionally, the Object Explorer consumes less screen "real estate" or surface area.

FIG. 1A is a block diagram of a computer system in which the present invention may be embodied.

FIG. 1B is a block diagram of a software system of the present invention, which includes operating system, application software, relational database management system, and user interface components.

FIG. 2 is a bitmap screenshot illustrating the basic architecture and functionality of a graphical user interface (GUI) which the system of FIG. 1B includes for communicating with a user.

FIG. 3A is a bitmap screenshot illustrating a preferred desktop interface for the system of the present invention.

FIG. 3B is an enlarged view of a toolbar from the interface of FIG. 3A.

FIGS. 3C-E are bitmap screenshots illustrating use of the Desktop's client area for displaying and manipulating major objects of the system, including table objects, form objects, report objects, and the like.

FIGS. 4A-4J are bitmap screenshots illustrating preferred design-mode and run-mode interfaces for the system of the present invention.

FIGS. 4K-M are bitmap screenshots illustrating the processing of events in the containership/event model employed by the system of the present invention.

FIGS. 5A-H are bitmap screenshots illustrating methods of the present invention for visual containership with auto-embedding of objects.

FIGS. 6A-M are bitmap screenshots illustrating methods of the present invention for providing objects with inheritance by context.

FIGS. 7A-D are bitmap screenshots illustrating methods of the present invention for providing a container-based name space for resolving object references.

FIGS. 8A-D are bitmap screenshots illustrating an Object Explorer interface of the present.

FIGS. 9A-B are bitmap screenshots illustrating use of the Object Explorer interface for indicating containership relations among objects.

FIGS. 10A-H are bitmap screenshots illustrating use of the Object Explorer for modifying properties and behaviors of objects of an application being created.

FIGS. 11A-B are bitmap screenshots illustrating dynamic updating of the outline view representing containership relations among objects, which occurs upon operations which affect an object (e.g., cutting, pasting, copying, moving, and the like).

FIGS. 12A-B are flowcharts illustrating an Object Explorer method 1200 of the present invention.

active: An ObjectPAL variable that represents the object that has focus.

application: An ObjectPAL type that provides a handle to the Desktop. Also a group of forms, methods, queries, and procedures forming a single unit, where users can enter, view, maintain, and report on their data.

argument: Information passed to a method or procedure.

blank: A field or variable that has no value.

bubbling: A process by which events pass from the target object up through the containership hierarchy.

built-in method: Pre-defined code that comes with every object a user can place in a form. Built-in methods define an object's default response to events.

clip object: An object that can be cloned by copy and paste operations via interprocess communication (e.g., Windows Clipboard). Both the methods and properties of the object are replicated, allowing for easy reusability.

clipboard: An interprocess communication facility available in Windows which employs a reserved area of memory to which data can be copied and from which previously copied data can be pasted to other applications.

compound (composite) object: An object made up of two or more other objects. For example, a table frame is a compound object made of field objects and record objects.

containership: One object contains another object if the other object is completely within the borders of the first object. Containership affects the availability (scope) of variables, methods, and procedures.

Database: An object type that contains information about relationships between tables.

data type: The type of data that a field or variable contains. The data type specifies the legal range of values that can be stored in the field of variable.

Desktop: The main window in the system.

dot notation: The use of a "." (dot) to qualify the name of an object's property or method.

Thus, MyButton.pushButton and YourButton.pushButton distinguishes the pushButton methods attached to MyButton and YourButton.

drag: Moving a screen object by holding down a mouse button while moving the mouse cursor to the target position.

Editor: The component of the system used to create and edit ObjectPAL methods.

event: The action that triggers a method (that is, causes code to execute). Also an objectPAL object type (Event).

event-driven application: An application where code executes in response to events, as opposed to a procedural application, where code executes in a linear sequence.

event model: The rules that specify how events are processed by objects in a form.

field: One item of information in a table. A collection of related fields makes up one record.

file: A collection of information stored under one name on a disk. For example, Paradox tables are stored in files.

focus: An attribute of an object. An object that has focus (also called the active object) is ready to handle keyboard input. Typically, the active or focused object is highlighted.

form: A window or "design document" for displaying data and objects. Also an ObjectPAL data type (Form). The form is the highest-level container object.

handle: A variable or pointer used to access and manipulate an object.

hierarchy: The relationship of objects in a form, derived from their visual, spatial relationship.

incremental development: A process of application development in which parts of the application can be progressively designed and tested interactively.

index: A file that determines the order in which Paradox can access the records in a table. The key field of a table establishes its primary index.

inspect: To view an object's properties and methods. To inspect an object, either right-click it or select it with the keyboard and press F6. When the object's menu appears, the chooses the property or method he or she wants to examine or change.

key: One or more fields in a table used to order records.

method: ObjectPAL code attached to an object that defines the object's response to an event.

object: An encapsulation of code and data. Entities that can be manipulated in the system are objects.

Object Tree: A dynamic diagram that shows how objects in a form are related in terms of containership.

parameter: The variable into which an argument is passed. Used in defining procedures.

procedure: Code bracketed by the keywords proc and endProc. Unlike a method, it has no object to give it context.

properties: The attributes of an object. One right-clicks an object to view or change its properties.

resize: Altering the size of a screen object by mouse-dragging a corner of the object to the target position.

run-time library: A collection of pre-defined methods and procedures that operate on objects in specific types.

scope: The accessibility or availability of a variable, method, or procedure to other objects.

script: A collection of ObjectPAL code that executes without opening a window.

Self: An ObjectPAL variable. Self refers to the object to which the currently executing code is attached.

target: The object for which an event is intended. For example, when a user clicks a button, the button is the target.

type: A way of classifying objects that have similar attributes. For example, all tables have attributes in common, and all forms have attributes in common, but the attributes of tables and forms are different. Therefore, tables and forms belong to different types.

variable: A named location in memory to store data that can be accessed and changed in programs using the given name.

The following description will focus on the presently preferred embodiment of the present invention, which is operative in the Microsoft.RTM. Windows environment. The present invention, however, is not limited to any particular one application or any particular windows environment. Instead, those skilled in the art will find that the system and methods of the present invention may be advantageously applied to a variety of system and application software, including database management systems, wordprocessors, spreadsheets, and the like. Moreover, the present invention may be embodied on a variety of different platforms, including Macintosh, UNIX, NeXTSTEP, and the like. Therefore, the description of the exemplary embodiments which follows is for purposes of illustration and not limitation.

The invention may be embodied on a computer system such as the system 100 of FIG. 1A, which comprises a central processor 101, a main memory 102, an input/output controller 103, a keyboard 104, a pointing device 105 (e.g., mouse, track ball, pen device, or the like), a display device 106, and a mass storage 107 (e.g., hard or fixed disk, optical disk, magneto-optical disk, or flash memory). Additional input/output devices, such as a printing device 108, may be included in the system 100 as desired. As shown, the various components of the system 100 communicate through a system bus 110 or similar architecture. In a preferred embodiment, the system 100 includes an IBM PC-compatible personal computer, available from a variety of vendors (including IBM of Armonk, N.Y.).

A. Overview

Illustrated in FIG. 1B, a computer software system 150 is provided for directing the operation of the computer system 100. Software system 150, which is stored in system memory 102 and on disk memory 107, includes a kernel or operating system (OS) 140 and a windows shell 145. One or more application programs, such as application software 125 or one or more windows application software 151, 153, 155, may be "loaded" (i.e., transferred from storage 107 into memory 102) for execution by the system 100. As shown, windows application software includes a Relational Database Management System (RDBMS) 155 of the present invention.

System 150 includes a user interface (UI) 160, preferably a Graphical User Interface (GUI), for receiving user commands and data. These inputs, in turn, may be acted upon by the system 100 in accordance with instructions from operating module 140, windows 145, and/or application modules 125, 151, 153, 155. The UI 160 also serves to display the results of operation from the OS 140, windows 145, and applications 125, 151, 153, 155, whereupon the user may supply additional inputs or terminate the session. Although shown conceptually as a separate module, the UI is typically provided by interaction of the application modules with the windows shell, both operating under OS 140. In a preferred embodiment, OS 140 is MS-DOS and windows 145 is Microsoft.RTM. Windows; both are available from Microsoft Corporation of Redmond, Wash.

B. Relational Database Management System

RDBMS 155 is a system that controls the organization, storage, and retrieval of information from a database. A database is an organized collection of related information or data stored for easy, efficient use. An address book is a database, as is the card catalog in a library, a company's general ledger, and a completed tax form. Thus, a database is a collection of one or more tables used to keep track of information, such as the information 161, 162, 163 of system 150.

In a preferred embodiment, RDBMS 155 includes Paradox.RTM. for Windows Database Management System, available from Borland International of Scotts Valley, Calif. General features and operation of Paradox.RTM. for Windows are described in the following Paradox.RTM. for Windows manuals (available from Borland): Getting Started, User's Guide, Quick Reference Guide, Guide to ObjectPAL.RTM., and ObjectPAL.RTM. Reference. The disclosures of each of the foregoing are hereby incorporated by reference.

C. Graphical User (Windowing) Interface

1. System UI

As shown in FIG. 2, the system 100 typically presents User Interface (UI) 160 as a windowing interface or workspace 200. Window 200 is a rectangular, graphical user interface (GUI) for display on screen 106; additional windowing elements may be displayed in various sizes and formats (e.g., tiled or cascaded), as desired. At the top of window 200 is a menu bar 220 with a plurality of user-command choices, each of which may invoke additional submenus and software tools for use with application objects. Window 200 includes a client area 230 for displaying and manipulating screen objects, such as graphic object 231 and text object 232. In essence, the client area is a workspace or viewport for the user to interact with data objects which reside within the computer system 100.

Windowing interface 200 includes a screen cursor or pointer 235 for selecting and otherwise invoking screen objects of interest. In response to user movement signals from the pointing device 105, the cursor 235 floats (i.e., freely moves) across the screen 106 to a desired screen location. During or after cursor movement, the user may generate user-event signals (e.g., mouse button "clicks" and "drags") for selecting and manipulating objects, as is known in the art. For example, Window 200 may be closed, resized, or scrolled by "clicking on" (selecting) screen components 222, 224/5, and 227/8, respectively. Keystroke equivalents, including keyboard accelerators or "hot keys", are provided for performing these and other user operations through keyboard 104.

In a preferred embodiment, GUI 200 is embodied in a message-based windowing environment. The general methodology for creating windowing interfaces and for retrieving and dispatching messages in an event-based GUI system, such as Microsoft Windows, is known in the art; see, e.g., Petzold, C., Programming Windows, Second Edition, Microsoft Press, 1990. Additional information can be found in Microsoft Windows Software Development Kit, including: 1) Guide to Programming, 2) Reference, Vols. 1 and 2, and 3) Tools, all available from Microsoft Corp. of Redmond, Wash. The disclosures of each of the foregoing are hereby incorporated by reference.

2. Desktop UI

In addition to the general windowing interface 200 for system 100, the system includes a preferred application development environment, employing a database programming language (ObjectPAL.RTM., available from Borland International). A preferred interface for the development environment will now be described. When a users starts the RDBMS system, a Desktop interface 300 first appears in display 106, as shown in FIG. 3A. The Desktop is the central working area in the system and serves as a "parent" window to all windows that appear in the system. It is where the user initiates all tasks. All windows are opened on the Desktop and are contained by the Desktop. Using the Desktop, the user can create and modify objects, set preferences, open and close files, and the like.

The Desktop may be divided into functional regions which include a main menu 310, a toolbar 320, a client area 350, and a status line 340. The menu bar 310 contains commands the user can choose to open windows, configure his or her Desktop, and work with his or her data. The menu bar is context sensitive, that is, it contains only the menus one needs at the moment. If a menu choice is not appropriate for a given task, it does not appear on the menu bar.

The toolbar 320 contains shortcut buttons for common menu commands. The toolbar 320, shown in further detail in FIG. 3B, comprises a row or palette of tools which provide a quick way for the user to choose commonly-used menu commands or properties. Like the menu bar, the toolbar buttons change as different windows are opened. To choose a toolbar button, one selects (clicks) it with the mouse. In an exemplary embodiment, the Desktop toolbar 320 includes Open (Create) Table 322, Open (Create) Form 323, Open (Create) Query 324, Open (Create) SQL link 325, Open (Create) Report 326, Open (Create) Script 327, Open (Create) Library 328, Add Folder Item 329, Remove Folder Item 330, and Open Folder 331 tools. The same actions are also available as corresponding commands in menus (available from menu bar 310). As with the menu system, toolbars are dynamic in the sense that only the tools available in a given context are displayed. The default action of a button (e.g., "Open" option of many of the buttons) is invoked by clicking the button with the left button of a two-button mouse device. An additional action (e.g., the "Create" option on certain buttons) is invoked by clicking the button with the right mouse buton.

The status bar 340 gives a user information about the task he or she is working on and the current state of the system. Like the menu bar and the toolbar, the appearance of the status bar changes as one works. As with the interface 200, standard Windows controls, like the title bar, the borders, the Control menu, the Maximize button, and the Minimize button are provided to let a user control the shape, size, and position of the Desktop.

Desktop 300 includes a client area 350, which functions in a fashion similar to that for the above-described Windows interface 200 (in FIG. 2) for displaying and manipulating screen objects of interest. In addition to simple text and graphic objects, the system provides the user with a set of sophisticated objects for storing and presenting his or her data. These will now be described in turn.

3. System Objects

(a) Tables and Design Documents

The system provides a set of objects including table, form, report, query, script, and library objects. As shown in FIGS. 3C-E, each type of major object in the system appears in its own type of window within the client area 350 and is itself comprised of objects. Table 361, for example, appears in a Table window 360; it comprises row and column objects 362, 363. Form 366 appears in a Form window 365 and includes (among other objects) an edit field object 369, a box object 368, and a text object 367. Similarly, Report 371 appears in a Report window 370 and includes, for instance, a report band object 374, a field object 372, and an edit field 373 (contained within the object 372). Each type of window includes specialized commands and functions that apply only to that type.

The windows are contained within the Desktop 300; here, the commands and functions of the Desktop remain available to all the objects. Once one learns to work with one type of object, he or she can work with similar objects. For example, when the user knows how to edit tables using Table windows, he or she can also edit tables using Form windows. When one knows how to design forms, he or she has the basics of designing reports.

While tables (e.g., Table 361) are the objects that users will use the most in the system, users will often want to display information in a format which is not tabular. For this purpose, the system provides "design document" objects. Form 366 of FIG. 3D and Report 371 of FIG. 3E are design documents, for instance. Each allows the user to customize how the user's data are presented. For instance, a user can create design documents that display one record at a time, display multiple records at a time, display only certain fields of a table, display design features (e.g., lines, boxes, graphic images, shading, or special colors), and the like. Design documents can also link together different tables, so that information stored in separate tables appears to the user to come from one place.

Forms and reports differ as follows. Forms are editing tools which let the user display and edit data in his or her tables. The user can, for example, create forms that add data to several tables at once. Reports, on the other hand, are printing tools. They allow the user to format and print his or her data. A user can, for example, use reports to create form letters, mailing labels, invoices, and the like. Unlike forms, reports cannot change the data in a user's table (though they can change the way his or her data appears on a final report).

Underlying the design document is one or more tables that contains the data which the user wishes displayed on screen or printed in a report. Thus, the task of creating a design document is one of choosing the table (or tables) that contains the data desired; defining the relationships between tables (in the instance of a multi-table design document), specifying the fields desired to be displayed in the design; and choosing an initial design layout for the document.

Thus, the system provides a set of objects including table, form, report, query, SQL, script, and library objects. Each type of major object in the system appears in its own type of window when opened/created via the appropriate toolbar button, menu selection, or hot key. Any number of these window types can coexist on the screen, either tiled or overlapping, as is known in the computing art. Each type of window includes specialized commands and functions that apply only to that type.

(b) Design Document interface

To create a new design document, the user first opens a design window for the type of document desired. For Form design, for instance, the system displays a Form Design Window 400 containing an empty Form object 450, as shown in FIG. 4A. This Form object is the result of either selecting the menu sequence File.vertline.New.vertline.Form from the desktop of FIG. 3A, or from a right-button mouse click on the Open/Create Form icon on the desktop toolbar. The Form Design Window 400 includes its own main menu 410, toolbar 420, and scroll bars 451.

The toolbar 420 includes editing and drawing tools for designing, updating, and testing the Form: Cut to Clipboard 421; Copy to Clipboard 422; Paste from Clipboard 423; View Data (Run Form) 424; Print 425; Selection Arrow 426; Box Tool 427; Line Tool 428; Ellipse Tool 429; Text Tool 430; Graphics Tool 431; OLE Tool 432; Button Tool 433; Field Tool 434; Table Tool 435; Multi-Record Tool 436; Graph Tool 437; Crosstab Tool 438; Data Model 439; Object Tree 440; and Open Folder 441. As with the menu sytem, toolbars are dynamic in the sense that only the tools available in a given context are displayed. For instance, if no data has been cut or copied to the clipboard, the Paste from Clipboard button will be dimmed and inoperable. The ruled border 452 serves as an aid for the designer when positioning boxes, buttons, and other objects inside the form.

Using the design interface, the user may place the objects he or she needs on the document. Then, the user may program the form by simply attaching methods to form objects and changing the property of the objects on the document until they appear as desired. This aspect will now be described in further detail.

D. Visual Design

1. Attaching methods to a button object

Referring now to FIGS. 4A-H, an exemplary session using the object-based visual programming methods of the present invention is illustrated. This example builds a program which provides a customized button that responds to a specific user event, a mouse click, by displaying a dialog box. In particular, the example shows how to attach program code (Borland's ObjectPAL.RTM. in an exemplary embodiment) to a button so that the code executes when the button is clicked.

The traditional way to demonstrate how to use a new language is to present a simple "Hello, world!" program--a program consisting of the minimum code needed to display the message "Hello, world!" on screen. The classic "Hello, world!" program in the C language, however, is not interactive. The program is simply executed and the message appears. In contrast, ObjectPAL is a language for creating interactive, event-driven applications. In the following "Hello, world!" application, the user controls when to display the message and when to put it away. The button is programmed to display a dialog box, but the code executes only when the user clicks the button.

Starting from the empty Form Design window shown in FIG. 4A, the programmer starts by clicking on the Button Tool icon 433 (shown in detail in FIG. 4B). This results in the display of a "default" button 453 with the generic name "LABEL" as shown in FIG. 4C. Like other properties of the button, the button name can be changed at any time during design. The button can now be "dragged" and "resized" to any position within the form using the mouse or equivalent keystrokes. Ruled borders 452 are provided to assist the designer in positioning and sizing the button.

The incremental development feature embodied in the invention lets the user test each step of the evolving program. If the user clicks the View Data (Run Form) toolbar button 424, the program is incrementally compiled and the screen switches from design mode to run mode. The toolbar changes to offer run mode options (as shown later in FIG. 4I). In run mode, the button can be clicked to test its default behavior. At this point in the example, since no event-handling methods have yet been attached to the button object by the user, the only effect of clicking the button is a purely visual change as the button seems to press into the screen. Releasing the mouse click restores the button appearance. These default actions are built into every button object so the programmer is not concerned with coding such behavior. The programmer continues by switching back to design mode by clicking the Form Design button.

Referring now to FIG. 4D, the method of the present invention for attaching methods to objects and changing the property of those objects will now be described. As shown in the figure, the button is "inspected" to reveal its current properties and methods. Specifically, the object is inspected by right mouse clicking the object. The first stage of inspection invokes a popup menu 454 from which the programmer can select a button property, such as Button Type, Center Label, or Design, or select the Methods menu item. Its properties determine its appearance. As shown, the Center Label property is on by default, as indicated by the check mark in the Center Label menu item. The other property menu items in 454 call up submenus when selected from which various properties, such as type and style, can be customized.

The button object itself is automatically assigned a generic name, shown as #Button3 in the menu title bar 455. Clicking on this bar invokes a button-name dialog box allowing the programmer to assign a more meaningful name, such as Hello Button, to the button object. This can be a useful mnemonic if later coding needs to refer to the button object. The button object name should not be confused with text displayed on the button. The latter is controlled via a Label Text property and can be set to any appropriate text string, such as "Press Me" or "Say Hello!".

Every object in a form (as well as the form itself) includes built-in methods that execute in response to events. A button object's methods include pushButton, action, menuAction, and so on, which determine what happens when the button is clicked. Specific actions to be triggered by the button can be achieved by editing the default methods or by writing new methods which are "attached" to the appropriate button object. To inspect the default methods attached to #Button3, the Methods . . . option of the menu 454 is selected; this invokes the Methods window 460, as shown in FIG. 4E. Window title bar 461 shows the name of the object being inspected. A Built-in Methods listbox 462 lists the built-in (default) methods already attached to the button. This list is scrollable (using the vertical scrollbar 469); particular methods can be inspected by double-clicking the target name or by selecting a method and then clicking on OK button 465. Selected methods can be unselected via Cancel button 467, or deleted by clicking Delete button 466. On-line help is available on-demand by selecting Help button 468.

The Custom Methods box 463 lists the names of additional custom (user-defined) methods that have been attached to the object being inspected. Additional custom methods may be defined using New Custom Method edit box 469. Radio buttons 464 allow the programmer to inspect any libraries, custom data types, variables, procedures, or constants associated with the current object.

The behavior of the button object can be varied in two ways: the built-in methods can be edited or new custom methods can be written. For the example at hand, the built-in pushButton method will be changed to make it respond to a push-button event by displaying a dialog box. This is achieved as follows. The user selects (e.g., double-clicks) the pushButton item in list 462, thereby invoking an Editor Window 470 as shown in FIG. 4F. This a full text editor with horizontal and vertical scrollbars 472/3. The editing tools in the toolbar 475 offer cut, copy and paste, as described earlier, together with printing options. A status bar 474 of the window displays the cursor position and editing modes. The title bar displays #Button3::pushButton, which is the "extended" or "qualified" name of the method; the notation allows this object's pushButton method to be distinguished from other objects' pushButton methods.

As shown in FIG. 4E, the Editor Window 470 displays the following two lines of code representing the default pushButton method:

The method definition allows the user to program steps which are to occur when a push-button event reaches this object. In addition to user-specified behavior, the object includes default behavior, for instance, the button appearance changes (to a pushed-in or depressed appearance) when the object is clicked. In a preferred embodiment, the steps of the built-in code are not displayed with the pushButton method; however, the system allows one to bypass the built-in code if desired. In general, the added code executes first, followed by the built-in code.

Continuing with the example, a line is added to the body of pushButton, as shown in FIG. 4G:

The added line calls msgInfo; this instruction creates a dialog box when the pushButton method is executed. msgInfo is a standard procedure in the system which is provided as part of an ObjectPAL run-time library--a collection of pre-defined methods and procedures that operate on objects or data of a specific type. msgInfo takes two arguments or parameters. The first argument, "Greetings", specifies the text to display in the title bar of the dialog box, and the second argument, "Hello, world!" specifies the text to display in the dialog box itself.

Before running the program, the syntax can be checked, as shown in FIG. 4H, by clicking Syntax Check button 482 on toolbar 481 or, alternatively, by selecting the menu sequence Language.vertline.Check Syntax. If there are errors, a message in the status bar 483 indicates the type of error. Otherwise, as shown in FIG. 4H, the message "No syntax errors" appears in the status bar and the edited code is saved. Errors can be corrected with the aid of the integrated debugger.

The program can now be executed by switching to run mode via the View Data toolbar button, as described earlier. FIG. 4I shows the result of clicking on the button in run mode: the action generates a push-button event which triggers the modified method #Button3.pushButton, which in turn calls the msgInfo function with the given arguments. The msgInfo function creates a Dialog box 490 having a title bar 491 displaying "Greetings" and a text body displaying "Hello, world!" 492 (as specified in the new pushButton method). Once the programmer is happy with the design, he or she can save the form with attached methods to disk.

2. Object reuse

The button created during foregoing session can be easily reused in the same or other applications with little effort. As shown in FIG. 4J, the user may select the button in design mode, copy it to the clipboard, and then paste it directly to another part of the same or another form. By switching forms, which leaves the clipboard unchanged, the button object can also be pasted into an entirely different application form. In both cases, all the properties and methods (built-in and customized) copy over to the target form. The "cloned" button will display and react to events in exactly the same way. Alternatively, the copy button can be further edited for the new application.

The present invention provides the same clipboard copy-and-paste reusability for all objects. At the user interface level, a preferred technique for cutting and pasting one or more objects may be summarized as follows. First, the user selects one or more objects desired to be cloned. This may be done by simply "clicking" on the object, or "shift-clicking" for selecting a plurality of objects. Next, the user selects Copy (e.g., by clicking the Copy button from the toolbar 420). Alternatively, the user would issue a Cut command if he or she desires removal of the original object or objects. A destination is then specified by the user, again using selection technique. To place an object in a new form, for instance, the user need only click in that new form for specifying it as the intended destination. To specify a container as the destination, the user need only select the container object (e.g., by clicking it). Finally, the user completes the operation by issuing Paste (e.g., by selecting the Paste button from the toolbar 420). In response, the system will create a clone of the selected object or objects at the specified destination. In the process, the system checks for any incompatibilities between object types (e.g., attempting to place one object in another object which cannot contain it).

This "clip object" functionality is provided by extending Windows clipboard format to carry all of the information that is needed for an object (or group of objects). In addition to standard data types, such as text, bitmaps, metafiles, and the like, Windows clipboard accommodates user-defined formats. A general discussion of Windows clipboard services and formats may be found in Petzold's Programming Windows, as well as Microsoft's Windows SDK documentation.

In a preferred embodiment, an object format is defined to transport information about the object, including: (1) type of object ("Who am I?"); (2) object properties; and (3) object methods. The latter may be considered to be yet another property of an object. A structure specifying a proprietary Windows clipboard format (PXClipFormat) may be created as follows:

where PXCF.sub.-- NF specifies a native object format. Once the format is registered with Windows, the system may cut and paste (memory blocks of) objects, including object properties and methods (e.g., stored as pcode). The system assumes responsibility for correctly interpreting the object format.

3. Event Model

All interactions with an application generate events. For each event, the system creates a packet of information and sends it to the form. By default, the form examines the event packet and dispatches it to the target object, which executes the appropriate built-in method. This behavior is governed by the event model. As previously stated, applications are developed by placing objects in a form and writing code to define how the objects respond to events. When users interact with these objects and generate events, the event-handling code executes. A single user action triggers a chain reaction of events and built-in methods that execute by default.

The system recognizes two kinds of events: internal and external. Internal events are triggered from within the system. Examples of internal events include opening and closing an object, arriving at and departing from an object, and timer events. External events are triggered by the user (or from within a method that simulates a user action). Examples of external events include keypresses, mouse clicks, and menu choices. Every design object has built-in default methods that respond to each of these events. For the convenience of the programmer, the system groups events into event classes: ActionEvent, ErrorEvent, Event, KeyEvent, MenuEvent, MouseEvent, MoveEvent, StatusEvent, and TimerEvent. The Event class handles general events while the others offer specialized services as their names imply.

A. Introduction

"Containership" is the notion that objects may be contained within other objects--"container" objects. For instance, the button object 453 of FIG. 4C is contained within the form object 452. Objects in a form coexist in a hierarchy of containers. For example, if a screen button is placed on a page of a form, the form contains the page, and the page contains the button.

An object's visual and spatial relationship to other objects within a containership model affects its properties and behavior. Position in the hierarchy is important since it defines what is "visible" (within "scope") to an object--what methods, procedures, properties, and variables of other objects are available. An object is "contained" if it is completely within the boundaries of the containing object. An object has direct access not only to its own methods, procedures, properties, and variables but also to those of objects within its containership scope. Containership, therefore, provides an intuitive, visual approach to object-based inheritance scheme.

Containership also provides yet another tool for reducing coding effort. This is perhaps best described by example. Consider a form containing a group of field objects. If there is a special action needed for each field, rather than attach the same custom code to each field object, a box can first be defined that surrounds the group of fields. Custom code can now be attached to this containing box. Since each field is contained in the box, the box's methods and custom code are made available to each field.

At the highest level in the containership hierarchy is the form itself; it is the starting container. If there is a special action needed for each object on a form, the user need only attach custom methods and procedures to the form to make them available to all objects contained by that form. The relationship between containership and scope applies not only to variables, but to object properties, custom methods and procedures attached to objects, the way objects handle events, and the way the system handles errors.

B. Event bubbling

Containership controls the way in which events are handled by the system. The containing form filters all events, both internal and external, for each of its contained objects. For internal events, the containing form knows the object target and passes on the event for immediate action. For external events, on the other hand, the system provides a mechanism, called event bubbling, for passing the event from object to object up a containership hierarchy until an object is reached that can fully handle the event.

Consider a form containing a button and a table frame. Objects will be placed on the form, and code attached to the button so that button clicks move the insertion point to the next column in the table frame. FIG. 4K shows such a form. The steps for creating it and attaching code are as follows. First, the user creates a blank form (e.g., by requesting File.vertline.New.vertline.Form from the Desktop). Next, the Button tool (433 of FIG. 4B) is selected to create a button 495 in the upper left corner of the form. The Table tool (435 of FIG. 4B) is invoked to create an empty table frame 496 to the right of the button. The table frame is renamed TFrame by inspecting it (as explained in the previous session), clicking the object's name from its menu, and typing the new name in the object-name dialog box. Now that the form design is complete, the next step is to attach code to the button so that the code executes when the button is pressed. The built-in pushButton method is edited as follows:

After closing the Editor window, the user may switch the system to run mode (using Form.vertline.View Data) to compile and run the form. Clicking the button at runtime moves the insertion point (highlight) in the table frame to the right after each click, until it reaches the rightmost field in the table frame.

The containership-based event model employed by the system of the present invention may now be understood by examining the event handling sequence which occur for the form of FIG. 4K. First, a mouse click generates an event, as shown in FIG. 4L. The event goes immediately to the containing form. The form knows which object is the target and acts as a dispatcher for the event. Because the mouse was clicked when the pointer was over the button, the form's built-in pushButton method executes, and by default calls the button's built-in pushButton method. Next, the button's pushButton method executes. The button appears pushed in.

When the attached statement in the pushButton method executes, it generates another event:

which again goes first to the form. The form interprets this event. The form's built-in action method executes, and calls the built-in action method of the object named TFrame. The default code for TFrame's built-in action method executes, even though no code has been added to it. The insertion point moves to the right. Finally, the default code (portion) for the button's built-in pushButton method executes, and the button appears to pop out. Processing for this event is complete.

As another example, FIG. 4M illustrates event message processing for an event (e.g., keystroke) occurring in a field of a table frame. As shown, the event is passed to the form which processes the event (if of interest) and then passes the event back to the field where the event occurred. Passing the event to the form first is particularly advantageous for trapping a particular event for all objects. From the form, the event is passed back down to the field where it bubbles up the containership chain for processing.

C. Visual containership with auto-embedding

Referring now to FIGS. 5A-F, methods of the present invention for embedding screen objects within other objects will now be described. FIG. 5A shows a blank form 500 displayed in a form design window; this blank form is created by simply invoking the command File.vertline.New.vertline.Form. Also shown is an Object Tree window 510. The Object Tree window displays a hierarchical tree listing the objects of the form. For the blank form 500, for instance, the Object Tree window 510 displays a tree having #Form1 (511) containing #Page1 (513). In this manner, the Object Tree schematically illustrates to the user that the form (which is given a default name of #Form1) contains a page (which is given a default name of #Page1).

Continuing with the example, FIG. 5B illustrates that the user has drawn a box 520 (using the Box Tool 427 of FIG. 4B). As shown in the figure, the Object Tree 510 has been updated to include an identifier for the box 520: #Box3 (521). As the Object Tree demonstrates schematically, #Box3 is contained within #Page1 (which in turn is contained within #Form1).

Additional objects will now be added to the form 500 to illustrate the feature of auto-embedding--when an object detects that it can be contained within another object it automatically embeds itself within that object. In FIG. 5C the user has drawn a button 530 and edited its default text ("LABEL") to display "Press Me!" 533. The button 530 is drawn with the Button Tool 433 (of FIG. 4B). As shown in the figure, the user has drawn the button 530 within the confines of the box 520. Accordingly, the button 530, since it may be contained within a box object, has auto-embedded itself within the box 520. This containership relation between the button 530 and the box 520 is illustrated schematically by the Object Tree window 510. Specifically, the tree displays a #Button4 (531) identifier for the button 530 and shows the button identifier 531 being contained within (i.e., a dependent of) #Box3. Also shown is a #Text5 (535) identifier which illustrates that the button 530 is itself a container for the text object 533; in this regard, the button 530 is a "composite object" which includes subobjects.

Continuing with the example, in FIG. 5D the user has drawn a second box 540 in the form 500. As can be discerned from the drawing, the box 540 is visually contained within the page, #Page1, which in turn is contained within the form. The Object Tree window 510 illustrates this relationship schematically. A #Box6 (541) identifier is shown as a dependent of #Page1. Just like #Box3, #Box6 has #Page1 as its immediate parent (container).

Having covered the basics of auto-embedding in a visual containership model, the reader may now progress to a more complex, drag-and-drop example. FIG. 5E illustrates a drag-and-drop operation by the user. Specifically, the user, using the pointing device (e.g., mouse), drags the button 530 from its original position 551 (contained within box 520) to new position 553 (contained within box 540). FIG. 5F illustrates the final result. As shown visually (by the figure) and schematically (by Object Tree 510), the button 530 has auto-embedded within the box 540, thereby establishing a new containership relation with the box 540 (and severing the old containership relation with box 520).

FIG. 5G illustrates interaction between objects having a containership relation. As illustrated by the arrow 560, the user attempts to resize the box 540. Since box 540 is the container or owner of the button 530, however, the box 540 cannot be resized such that it violates its contained-within objects, button 530 in this instance. As illustrated by line 561, the resizing of box 540 is constrained so as not to violate or "dis-embed" the button 530. This container-integrity feature may also employed when pasting a clipboard object to a destination container. Specifically, the destination container may be automatically reconfigured (e.g., resized) so that it appropriately accommodates the candidate object. Alternatively, the system may forewarn the user that the destination container cannot accommodate the candidate object.

Finally, FIG. 5H illustrates the user operation of resizing box 520 (to box 520') so that it contains the box 540 and the button 530. As shown by the Object Tree window 510, in response to the user resizing the box 520 to visually contain the box 540 and button 530, the system auto-embeds the box 540 and the button 530 within the box 520'. Thus, as illustrated by FIGS. 5A-H, the system of the present invention provides a visual containership programming model which allows objects to be embedded within other objects using simple drag-and-drop techniques. Moreover, the system provides simultaneous schematic information of the containership hierarchy of a form by use of a Dynamic Object Tree. If desired, the user may disable the containership interaction for an object by changing a Contains Object property to False (as described above).

Objects in the system of the present invention include built-in knowledge of the types or classes of objects which they may be embedded within. For instance, a button object may be embedded within a box object, as demonstrated above. A box object cannot be embedded by the user within a text object, for instance. One should be careful not to confuse embedding with overlaying. Embedding establishes a containership relation between, with programatic consequences; if desired, however, the user may merely overlay objects without invoking a containership relation. With built-in knowledge of compatible classes, objects in the system are self-monitoring: objects will only allow the user to auto-embed objects of containership-compatible types.

D. Inheritance by context

FIGS. 6A-M illustrate use of visual containership of the present invention for simplifying the task of attaching program code to objects. As discussed above, objects have available for their use (i.e., within their "scope" or "visibility") various methods and data structures. Exactly which method or data structure is invoked by a particular object depends on the context of the object--where it is located. This aspect will now be demonstrated.

FIG. 6A illustrates the runtime appearance of a simple form, form 600. The form includes several objects. The object composition of the Form 600 is perhaps best demonstrated by switching to Design mode (as previously described), as shown in FIG. 6B. In Design mode and using Object Tree 605, one sees that the form 600 includes a page 640 having a box 610 and a box 620. Box 610 in turn contains a text object 613 and a field object 615. Box 620, on the other hand, only includes a text object 623. The containership relation between these various objects is schematically represented by the Object Tree 605.

When the user selects a particular object (e.g., by clicking on it), the Object Tree highlights the particular object being selected. In FIG. 6C, for instance, the user has selected box 610 (selection indicated by selection handles--bounding rectangles), whereupon the Object Tree window 605 now highlights #Box3 (611) identifier, the identifier corresponding to box 610. FIG. 6D illustrates that selection of Field object 615 causes #Field5 (616) identifier to be similarly highlighted.

Continuing with the example, the user will now attach a method (program code) to the box 610, as illustrated in FIGS. 6E-G. In FIG. 6E, the user invokes the inspector popup menu for the box 610 (e.g., by right-clicking it). The popup includes a Methods choice 650. Upon selection of the Methods choice 540 by the user, the system displays a Method dialog box 651, as shown in FIG. 6F. The user adds a custom (i.e., user-defined) method named "flash" 653. As shown by Method edit window 655 of FIG. 6G, the user has defined the method "flash" to include steps which tell an object to flash itself on and off (by toggling its visible property).

Next, in FIG. 6H, the user will attach a method to the field object 615. As before, the user invokes the inspector dialog for the object (e.g., by right-clicking the object). Upon the user selecting the Methods option for the field object 615, the system displays Method dialog box 661, as shown in FIG. 6I. Here, the user will select the mouseClick built-in method for specifying a desired action (for the object when it is clicked with the mouse). FIG. 6J shows the Edit window for the mouseClick method: Edit window 665. As shown in the figure, the user has edited the mouseClick method to include executing the "flash" method. In other words, when the object is clicked with the mouse (i.e., receives a mouseClick event), the object will execute the "flash" method which causes the object to flash on and off (as specified by the program steps of the flash method (shown previously in window 655 of FIG. 6G). Running the form at this point (i.e., runtime mode shown in FIG. 6A), therefore, causes the field object 615 to flash intermittently whenever it is clicked with the mouse.

As will now be illustrated by FIG. 6K, the user may drastically change the behavior of the field object 615 by simply dragging it from one container (box 610) to another container (box 620). Recall that, according to the present invention, methods attached to an object remain with that object throughout cutting, pasting, moving, and the like. Thus, the previously-defined mouseClick method (which includes a call to a "flash" method) remains with the field object 615, despite having been moved to a new container (box 620). At this point it should be appreciated that while the "flash" method of the box 610 was available to the field object 615 when the field object 615 was contained within the box 610, movement of the field object 615 to a new container severs the previously-inherited behavior (of flashing on and off). Instead, the field object 615 inherits by context the "flash" method for its container, box 620. As shown in FIG. 6L, the "flash" method for the box 620 has been defined by the user to cause an object to change color (as shown by the method steps in the Method Edit window 670). Thus at this stage, when the form is executed the act of clicking on the field object causes the object to change colors (since it has inherited this new behavior by context).

Finally, FIG. 6M illustrates the impact of dragging the field object to yet another context. As shown by the figure, the field object 615 is now contained within the page 640. Page 640 includes a "flash" method which instructs an object to beep 20 times. At this stage, when the form is executed an action of clicking on the field object 615 will cause the object to beep 20 times. Thus, FIGS. 6A-M have illustrated inheritance by context--that is, the method of the present invention where an object inherits a particular behavior as a result of its containership location (i.e., context).

E. Name space

Every object in the system has a name. If a name begins with a # sign, then it is a default name assigned by the system (e.g., #Box3). The user may rename objects, as desired. For instance, #Box3 may be renamed to Fred; #Box6 may be renamed to Bob. A form containing a Fred box and a Bob box is illustrated in FIG. 7A.

Within an ObjectPAL source listing, objects are referred to by name. "Dot" expression is used to associate a method call or property with a particular object. For example, the statement

sets the Color property of boxOne to blue. Several objects may have a method named action, so to call the action method of the OrderTable object one needs to write OrderTable.action.

Since objects are referred to by name, names at a given level (containership scope) should remain unique. The system of the present invention automatically adjusts names to retain this uniqueness. As shown in FIG. 7B, when the Fred box is copied and pasted to a new location on the page (#Page2), then its name is automatically adjusted to a new, unique name (e.g., Fred1). Notice, however, that when a copy of Fred is pasted into Bob, Fred need not have its name adjusted since it may be uniquely addressed (by virtue of its containership within Bob). This is illustrated by FIG. 7C. Specifically, the original Fred has a full address of #Form1::#Page2::Fred. The Fred box contained within Bob, on the other hand, has a full address of #Form1::#Page2::Bob::Fred. Accordingly, each is uniquely identified.

The consequence of this name space is as follows. When an object refers to another object by name, the system resolves the reference by examining the containership relation between objects. If the Joe button in FIG. 7D, for instance, refers to a Fred object, that reference will be resolved to the Fred object which is within the same containership scope. Therefore, the name space itself is also context sensitive.

Another aspect of the name space is the notion of "noise names." As shown in FIG. 7D, for instance, the full address of the Joe button is: #Form1::#Page2::Bob::Joe. For the convenience of the programmer, the system allows "noise" names, such as #Form1, to be omitted without consequence. Thus, the Bob box may be simply referred to as "Bob" without having to specify its immediate containers. Similarly, a reference to MyForm.#Box5.MyButton can be shortened to MyForm.MyButton without ambiguity. The #Box5 object is part of the containership hierarchy for custom code and variables, but the object's name is optional. Because #Box5 is the object's default name, it is not required in the containership path. This feature is convenient when objects need to be placed in a form for purely cosmetic reasons, without worrying about naming them and addressing them to get to the objects that do the real work.

The name space employed by the system also leads to enhanced system performance. For instance, whenever it is necessary for the system to notify all objects of a container (e.g., to redraw themselves), the system need only traverse the nodes of the Object Tree which are contained within that container. Accordingly, the visual containership hierarchy allows the system to rapidly process events which occur in the system. In a system with a flat space (i.e., no containership), in contrast, an event, such as a mouse click, would require that all objects be processed to determine whether the event affects them.

A. General Introduction

In an alternative embodiment, the object inspector and object tree hierarchy are collapsed into a single UI (user interface) element--an "Object Explorer" of the present invention. In the previously described embodiment, both the object inspector and object tree existed, but in separate places. The disadvantage of such an approach is that the user is required to switch back and forth between these two user interface elements. Additionally, the prior approach of presenting these individually consumes an excessive amount of screen "real estate" (i.e., surface area).

B. Object Explorer

FIG. 8A illustrates a form designer 800 in which the user has undertaken form-based creation of an application by placing a screen button 811 on screen form 810. In conjunction with this step, the user has invoked Object Explorer 820, for example by "inspecting" (e.g., right clicking) on the sample button 811. In a preferred embodiment, display of the Object Explorer can be made persistent upon the user selecting a corresponding preference setting. Alternatively, the explorer can be invoked upon inspection of an object, in the manner previously described.

An enlarged view of the Object Explorer 820 is shown in FIG. 8B. The left hand view 830 of the Object Explorer comprises a hierarchical outline view of the objects on the form. As shown, the view has "drilled down" to the currently selected object, the sample screen button which was shown selected in FIG. 8A. The right hand view 840 of the Explorer comprises a tabbed property inspector. The property inspector shows the properties, methods, and events for the currently-selected object (here, the sample button).

C. Outline view of containership relations

The outline view 830 presents a schematic representation or view of the containership of objects within the program under development. As shown, for instance, the highest-level object is the form, which is represented by outline node 831. The form is itself an object, with properties, methods, and events. On the particular form shown in the example of FIG. 8A, a single page is present. This page object is represented in the outline by node 833. The page includes a button, sample button 811. This is represented in the outline as button node 835.

The right-hand view 840 of the Explorer comprises Properties, Events, and Methods Property Sheets. As shown in FIG. 8B, for instance, a set of properties sheet 841 is shown, for the currently selected object--the button object (as indicated by node 835). Here, the user can modify the button to customize its appearance and functionality. Objects within the system include a collection of self-contained properties that define the object. Properties include, for instance, color, numeric format, text style, or the like. Complex objects, such as database tables, can have additional properties. A table, for instance, has properties for each column and each heading in the table.

The user can easily invoke the "Methods" Property Sheet (e.g., by clicking on the "Methods" tab), as illustrated in FIG. 8C. Methods comprise data declarations (e.g., variables or "VAR") and functions which the user has created and attached to an object. The Methods Property Sheet 842, therefore, serves to list the methods defined for a selected object. To edit contents of a particular method, the use can select the method (e.g., by clicking on it) from this list.

To list the events for a selected object, the user selects the "Events" tab. As shown in FIG. 8D, an "Events" Property Sheet 844 includes a list of events defined for a selected object. An event is an action that triggers a built-in method of the system. For instance, the action or event of pushing a button triggers a built-in "pushButton" method. The method itself can include user-specified functionality (in addition to default behavior). As another example, the action of clicking a mouse on an object invokes an "onClick" method.

The system includes an editor for editing events and methods, so that the user can add new functionality to an object. In this manner, the user can assign functionality to a screen button by editing its "onClick" event.

D. Selection of objects

The design objects in the system remain synchronized with the corresponding outline view such that user's selection of a particular object causes the corresponding node in the Object Explorer to also receive corresponding focus. By the same token, user's selection of a particular node in the outline causes the corresponding object on the design surface to receive focus. This facilitates user selection of a particular object (or objects). During creation of a complex form--that is, one containing numerous objects--the user might find it easier to locate a particular object by navigating the outline hierarchy. Here, the user can gain instant access to a particular object despite the fact that it might be nested or otherwise obscured by multiple objects on the form being designed.

Even though the example of FIGS. 8A-D illustrate use of the Object Explorer with the simple example of a screen button, the button itself is actually contained within a page (i.e., page object) which, in turn, is contained within a form (i.e., form object.) This "nesting" of objects within other objects can occur to an arbitrary level. Each of these has its own set of methods, events, and properties. This is illustrated by FIGS. 9A-B. In FIG. 9A, selection of the page 903 (or selection of the corresponding page node 901) displays the methods, events, and properties for the page object. As shown at this point, the page contains the button and, in turn, is contained by the form. Selection of the form 913 (or its corresponding form node 911), on the other hand, causes the Explorer to display the methods, events, and properties for the form object.

The Explorer also provides visual cues to assist the user. The nodes in the outline, for instance, include glyphs displaying an icon for a corresponding object type. For instance, a form node includes, in addition to its name, an icon representing a form object. A node for a button object, on the other hand, includes an icon illustrating a button object. Display of the properties also includes visual clues. Read only properties (i.e., those which cannot be changed by the user), for instance, are displayed in the color red (or other desired color scheme). In this fashion, the user can discern at a glance whether a property can be altered by the user.

E. Demonstration of user operation of the Object Explorer

Use of the Object Explorer of the present invention is perhaps best demonstrated by way of example. Accordingly, the following will repeat the previously-illustrated "flash" method containership example of FIGS. 6A-M, but this time using the Object Explorer as now illustrated by FIGS. 10A-H.

FIG. 10A illustrates a simple form 1000, in design mode. Using the Object Explorer, shown at 1001, one sees that the form 1000 includes a box 1010, a box 1020, a sample button 1005, as well as other elements (e.g., form object, page object, and text objects). In FIG. 10A, the box 1010 has focus--it is the currently-selected object on the form. Accordingly, corresponding box node 1011 is highlighted in the Object Explorer 1001. Now, programming code is to be attached to the box by selecting "New Method" choice from the "Methods" Page, as shown at 1013. The system responds with a "New Method" Dialog 1015, shown in FIG. 10B, whereupon the user enters a name for the new method being created.

For the example at hand, the new method is called "flash" and includes method steps instructing the box (here, the "self" member) to change its color first to green and then to white. Actual entry of the script for defining these steps is shown at 1031, in FIG. 10C. This method is somewhat similar to the "flash" method created for the box object 620 previously shown in FIG. 6K, except here the action is to affect the container (box), not the sender (button).

FIGS. 10D-E illustrate comparable steps for defining a second "flash" method, this time for the box 1020. First, as shown in FIG. 10D, the box 1020 is selected r (e.g. by clicking on it), or the corresponding box node 1021 is selected. Either action causes the box 1020 to receive focus on the form and, at the same time, the box node 1021 to be selected in the outline. Additionally, the methods, events, and properties for this object--box 1020--are now currently displayed by the Object Explorer. For the second "flash," method steps are entered for making the sender object ("subject") flash on and off, by setting its "visible" property first to false and then to true. The script for defining the steps is shown at 1033, in FIG. 10E.

As previously illustrated by FIG. 6K for the field object 615, the user may now drastically change the behavior of an object by simply dragging it from one container (in the present example, box 1010) to another container (box 1020). Recall that the methods and properties attached to an object remain with that object throughout cutting, pasting, moving, and the like. Thus, the pushButton event handler or method (which includes a call to a "flash" method) remains with the button object 1005, despite having been moved from one container to another.

Which "flash" method actually gets executed at runtime when pressing the button 1005 depends upon the "context" of the button--where (i.e., what container, if any) it is currently located. In FIG. 10H, for instance, placement of the button 1005 within the box (container) 1020, as indicated t 1051, causes the button to flash on and off (i.e., toggle its "visible" property from false to true), since it inherits by context the "flash" method of its container, box 1020. In a corresponding manner, moving the button 1005 to the box 1020 severs this inherited behavior (of flashing on and off). Instead, the button 1005 triggers the "flash" method of the box 1020, thereby causing the box (i.e., the "self" target) to flash colors (not shown).

F. Dynamic updating of outline

All operations which affect the containership relationship between objects are immediately reflected in the Object Explorer. For instance, as soon as the button 1005 is moved from the box 1010, the outline is updated to reflect the new containership relationship. In FIG. 11A, for instance, while the button 1005 resides within the box 1010, the outline appears as shown at 1101: the button is shown as being contained by the box 1010. Upon movement of the button 1005 outside of the box 1010, on the other hand, the outline dynamically and immediately changes as shown at 1103 in FIG. 11B. Here, the button is no longer contained within the box; therefore, its corresponding node is not shown as being a descendent or a child of the box. Additionally, a desired object (with or without its own containees) may be moved to a particular target container by dragging its corresponding outline node to the node of that container (or pasting the node to that container node). If the container can accept the object (as described above), the object will be pasted or moved into that container while, at the same time, the outline view updates to reflect the new relation(s).

Thus, FIGS. 10A-H have illustrated inheritance by context (as previously illustrated in FIGS. 6A-M) for the purpose of illustrating use and effectiveness of the Object Explorer of the present invention, which affords quick access to methods, events, and properties of objects which exist in a hierarchical relationship.

G. Internal operation of Object Explorer

FIGS. 12A-B illustrate an Object Explorer method 1200 of the present invention. At step 1210, a user event is received requesting object exploring. This may occur as a result of the user requesting the Object Explorer as a menu item (or toolbar button equivalent), or requesting it from a pop-up menu (i.e., by right clicking on an object). Any one of these events generates a message which is posted to the desktop which ultimately leads to invocation of the Object Explorer. Specifically, at step 1211, the constructor (e.g., C++ (or C with objects) Class Constructor) for the Object Explorer is invoked.

The constructor itself performs many chores. At the outset, it creates the necessary windows and data structures for supporting the Object Explorer. It also loads the latest set of preferences set by the user. Then, at step 1212, the constructor determines the active form window (i.e., the form being used by the user) and whether the form window is in design mode. Then, at step 1213, it determines the "best" object to call--that is, the object which is given focus. The constructor makes this determination generally of "best object" among one of the following:

(1) the "active" object (an internally-maintained member of the form);

(2) the object last receiving a mouse click (i.e., user selection);

(3) the currently selected object (if there is only one); and

(4) the form itself (if nothing is selected). From these, the Object Explorer "selects" the best object, as indicated at step 1214.

Having selected an object, the Object Explorer now updates the object tree to display a corresponding node for the selected object, as shown at step 1215. Here, the Object Explorer makes sure that the object tree has scrolled the object (glyph and node) into view on the tree. At step 1216, the Object Explorer highlights the node in the object tree which corresponds to this selected object. Now, the topmost pane is determined and is requested to "populate" its list. Each of the PME panes corresponds to an object which knows best how to populate its window with appropriate information and how to best handle user input. Each PME pane itself can be implemented in a conventional manner as a "list" control; special glyphs and icons can be created as "owner drawn" controls.

At this point, the Object Explorer displays the hierarchical object tree with the appropriately selected node; a PME pane relevant to that node is displayed with a list populated with information relevant to the selected object. At step 1220, the method gets the next event which occurs in the system. Exemplary event processing is indicated at step 1221. In the event that the user requests a change to another PME pane, the appropriate pane is told to "populate" its list, as indicated at step 1222. If the user clicks on a tree node, the corresponding object executes a built-in method to select itself, as indicated by step 1223.

If, instead, a new object has focused (e.g., the user has selected a new object with the mouse device), the method loops back to step 1215 to update the object tree to display the appropriate node for the newly-selected object. If, on the other hand, a new window has focused (e.g., the user has opened a new form), then the method loops back to step 1211 to invoke the Object Explorer's constructor, thereby creating a new Object Explorer instance for the new form window. Finally, if the user selects to close the Object Explorer, at step 1221, then the Object Explorer closes at step 1224, performing any cleanup needed (e.g., deallocating memory and resources).

Source listings, presented in the C programming language (with objects), are appended herewith as Appendix A, for providing further description of an exemplary implementation of the Object Explorer of the present invention. A suitable development system for compiling and linking such listings is available from several vendors, including Borland International of Scotts Valley, Calif., and Microsoft Corporation of Redmond, Wash. Further description of the system and methods of the present can be found in user and programmer guides and additional reference materials providing additional description for the present invention, as implemented in a commercial embodiment marketed under the tradename of Paradox.RTM. 7 for Windows, available from Borland International.

While the invention is described in some detail with specific reference to a single preferred embodiment and certain alternatives, there is no intent to limit the invention to that particular embodiment or those specific alternatives. Thus, the true scope of the present invention is not limited to any one of the foregoing exemplary embodiments but is instead defined by the appended claims. ##SPC1##