Development system with visual designer tools (Designers) are described for generating and modifying program code. During system operation, a user employs the Designers to visually create an application program and generate a source file. Moreover, the user can proceed to edit the file with a text editor and then return to the Designers to edit the form visually. Each Designer is a bi-directional or "two-way" tool: the user can modify a form either visually with a Designer, or by editing the generated code in a source (text) file with a text editor. The user can use both techniques interchangeably--switching at will. All changes which occur in Designers are reflected in the generated code and vice versa.

Current U.S. Class:	717/105; 717/113; 717/140
Current CPC Class:	G06F 8/34 (20130101)
Current International Class:	G06F 9/44 (20060101); G06F 009/46 ()
Field of Search:	;395/701,702,703,704,705,200.48 ;364/280.7,970,977.1,977.3,280.4,286,286.3 ;345/326,349 ;707/514

Smart; John A.

---

Claims

---

What is claimed is:

1. In a system for developing applications programs, said system having a processor, a memory, and a storage device, a method for generating program code for an application program, the method comprising:

(a) displaying a design surface having a form, said design surface including a plurality of types of objects which can be placed on said form to create said application program;

(b) receiving user input for visually placing desired ones of said types of objects on said form;

(c) in response to step (b), creating in-memory objects of the type desired by the user, said in-memory objects including display methods which support design-time display of said objects at said design surface and further including streaming methods which support storage of a source code representation of said objects on said storage device;

(d) in response to step (c), invoking said display methods of said in-memory objects, so that visual representation of said objects appear at said design surface;

(e) receiving user input requesting automated generation of source code for at least some of the objects that have been placed on the form; and

(f) in response to step (e), generating source code for at least some of the objects that have been placed on the form by invoking said streaming methods of at least some of said in-memory objects, so that a source code representation of those objects is automatically generated by the system as a source file for storage on said storage device.

2. The method of claim 1, wherein said types of objects include user interface controls.

3. The method of claim 2, wherein said user interface controls include menus, pushbuttons, and scroll bars.

4. The method of claim 1, wherein said streaming methods of an object include steps for generating a textual representation of the object.

5. The method of claim 1, wherein said display methods of an object include steps for generating a visual representation of the object on a screen device.

6. The method of claim 1, further comprising:

(g) receiving a user request to further modify said objects visually; and

(h) in response to step (g), performing the steps of:

(i) executing said source file so that said objects are re-created in-memory; and

(ii) posting a message to said objects to design themselves, so that a visual representation of said objects is again displayed at said design surface.

7. The method of claim 1, wherein said textual representation of said objects comprises program code necessary for re-creating said objects in-memory.

8. The method of claim 1, wherein said textual representation of said objects include class definitions of said objects.

9. The method of claim 8, wherein said textual representation further include steps for instantiating said objects from said class definitions.

10. The method of claim 1, wherein said user input in step (b) includes input from a user input device for selecting a particular object type and placing an object of that type at a particular position on said form.

11. The method of claim 10, wherein said user input comprises input received from a pointing device in response to operation by a user.

12. The method of claim 1, wherein said user input comprises user input for changing properties of at least one of said in-memory objects.

13. The method of claim 12, wherein said user input for changing properties of at least one of said in-memory objects comprises user input for changing appearance at least one of said in-memory objects which is displayed.

14. The method of claim 1, further comprising:

in response to a user request, executing said program code generated for said application program, said application program executing under control of an end user.

15. The method of claim 1, further comprising:

receiving user input for editing said source code representation so as to modify said objects;

receiving a user request for further visually designing said objects; and

repeating steps (c) and (d), so that visual representation of said objects, as modified, appears at said design surface.

16. In a development system, an improved method for creating an application program, the method comprising:

(a) providing different classes of objects for placement on a form displayed on screen at design time using graphical user interface technique, each object being created from a particular class of objects and being suitable for use at both design time and at runtime, each class providing display methods for representing objects of that class on screen both at design time and at runtime;

(b) at design time, receiving a first request from a user for placing a particular object on said form;

(c) in response to said first request;

(i) creating from the class of the particular object an instance of the particular object in memory;

(ii) sending a message to the particular object to display itself; and

(iii) in response to said message, invoking the display methods of the particular object's class, for providing a visual representation of the particular object on screen at design time;

(d) during design time, receiving user input for modifying properties of said particular object;

(e) upon the user concluding design, streaming the particular object out to a storage device as a source code representation of the particular object;

(f) compiling said source code representation of the particular object into a compiled application program;

(g) receiving a second request from an end user for executing said compiled application program; and

(h) in response to said second request;

(i) creating from the class of the particular object an instance of the particular object in memory;

(ii) sending a message to the particular object to display itself; and

(iii) in response to said message, invoking the display methods of the particular object's class, for providing a visual representation of the particular object on screen at runtime;

wherein said particular object is responsible for displaying itself both at design time and at runtime.

17. The method of claim 16, wherein said different classes of objects comprise classes for various user interface objects.

18. The method of claim 16, wherein step (c) further comprises:

sending a message to the particular object to design itself; and

in response to said message to the particular object to design itself, invoking methods of the particular object's class, for entering a design mode for modifying the particular object at design time.

19. The method of claim 16, further comprising:

sending a message to the particular object to stream itself to a storage device, for writing to the storage device a textual representation of the particular object; and

in response to said message to the particular object to stream itself to a storage device, streaming said particular object to the storage device by saving a current state of the particular object as a textual representation in a disk file.

20. The method of claim 19, wherein the current state of said particular object includes object properties represented in memory as a series of name/value pairs for the object.

21. The method of claim 19, wherein said textual representation comprises source code of the application program which is necessary for recreating said particular object in-memory, as modified by the user at design time.

22. The method of claim 21, wherein said source code includes a class definition of the particular object's class.

23. The method of claim 21, wherein said source code includes a textual representation of said name/value pairs for the object.

24. The method of claim 16, wherein step (d) includes:

displaying a property inspection dialog for receiving user input for setting properties of all objects;

querying the particular object for enumerating specific properties supported by the particular object; and

displaying at said property inspection dialog the specific properties supported by the particular object.

25. The method of claim 24, wherein said property inspection dialog has no knowledge about the properties of the particular object prior to the particular object being queried for its specific properties.

26. A computer system with visual development tools supporting source code generation for a computer program being developed, the system comprising:

a computer having a processor and a memory;

means for designing an application program by displaying a user interface that allows a user to visually place actual objects of different classes from the computer program on a form on screen and modify properties of those objects, each class comprising class methods; and

means for rending a particular object that is an actual object from the computer program on screen at both design time and at runtime, including:

means for supporting a design-time view of the particular object, by posting a message to the particular object to display itself during design time; and

means for supporting a runtime view of the particular object, by posting a message to the particular object to display itself during runtime;

wherein said means for supporting a design-time view and a runtime view of the particular object invokes a particular display method of the particular object's class.

27. The system of claim 26, wherein said means for designing an application program includes:

an input device for selecting an object of a certain class and positioning that object on the form.

28. The system of claim 26, wherein said means for designing an application program by placing objects of different classes on a form on screen includes:

means for creating at design time in-memory instances of the objects of different classes which are placed on the form.

29. The system of claim 28, wherein each instance of an object created at design time has, during design time, access for invoking the class methods for its class.

30. The system of claim 26, further comprising:

means for rending the particular object as a textual representation on disk, including means for invoking at least one streaming method for streaming the particular object to disk as program code necessary for recreating said particular object in-memory.

---

Description

---

COPYRIGHT NOTICE

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.

BACKGROUND OF THE INVENTION

The present invention relates generally to the field of computer systems and, more particularly, to systems and methods for automating the task of developing application programs.

Before a digital computer may accomplish a desired task, it must receive an appropriate set of instructions. Executed by the computer's microprocessor, these instructions, collectively referred to as a "computer program," direct the operation of the computer. Expectedly, the computer must understand the instructions which it receives before it may undertake the specified activity.

Owing to their digital nature, computers essentially only understand "machine code," i.e., the low-level, minute instructions for performing specific tasks--the sequence of ones and zeros that are interpreted as specific instructions by the computer's microprocessor. Since machine language or machine code is the only language computers actually understand, all other programming languages represent ways of structuring human language so that humans can get computers to perform specific tasks.

While it is possible for humans to compose meaningful programs in machine code, practically all software development today employs one or more of the available programming languages. The most widely used programming languages are the "high-level" languages, such as C or Pascal. These languages allow data structures and algorithms to be expressed in a style of writing which is easily read and understood by fellow programmers.

A program called a "compiler" translates these instructions into the requisite machine language. In the context of this translation, the program which is written in the high-level language is called the "source code" or source program. The low-level or machine language, on the other hand, comprises "object code." Once created, object code (e.g., .obj file) is a separate program in its own right--it includes instructions which may be executed by the target microprocessor. In practice, however, the object code is usually first linked (i.e., combined) with other object code or libraries, which include standard routines.

Compilers are fundamental to modem computing. Translating human-oriented programming languages into computer-oriented machine languages, compilers allow computer programmers to ignore the machine-dependent details of machine language. Instead of focusing on the register set or memory architecture of a particular computer, for instance, one may simply concentrate on solving the problem at hand. Thus, high-level languages are "portable," that is, they afford a level of abstract which permits a single program to be implemented on several different machines, including ones of vastly different architecture.

The task of handcrafting source code suitable for compilation into a program by a compiler has always been a labor-intensive chore. Accordingly, there has been much interest in improving the process. A particularly popular approach to this problem is to use "application generators" or "code generators." These are programs which generate basic source code for application programs. Examples include Borland's AppExpert, Microsoft AppWizard, and Borland's dBASE AppGen. Typically, a developer user provides such a tool with some initial input, for indicating the type of application program desired. The type of programs desired may include, for instance, a 16-bit Windows application with OLE (Object Linking and Embedding) capability and an MDI (Multiple Document Interface) interface. Based on these inputs, a typical application generation tool would generate complete source code for a working program which includes the attributes specified by the user. The program generated is essentially a "shell" program--that is, a bare-bones program which lacks core functionality for completing end user tasks. Thus, conventional application generators automate the task of writing the "boilerplate" code, which is necessary to get a program at least up and running.

In addition to receiving information regarding a particular type of application desired, application or code generators can also create source code in response to developer user input which "paints" an interface. Such a tool, such as Protogen.TM., allows the user to visually create an interface, using standard drag-and-drop methodology. After the interface is created, the developer user instructs the tool to generate the source code for the application program. In response, the application generation tool generates source code text files which include the necessary code for recreating and operating the user interface.

After the user has generated the shell program, he or she proceeds to add specific functionality to the program, using conventional coding techniques. The user may, for instance, write functions or procedures which operate in response to user selection of choices from a menu bar. The basic code for displaying the menu bar and getting end user choices was generated by the application generator. The developer user retrieves this code into a program editor and adds additional routines or functions for carrying out the application programs functionality which is to operate in response to end user selection of menu choices.

Although conventional application generators clearly facilitate the task of creating programs, they have a distinct disadvantage. In particular, these tools are all monolithic or "one-way" tools. Once the user has generated the source code for the application program and then modified it to include his or her functionality, the user cannot "go back" to the application generator to regenerate the code. If the user forgot to add a particular menu choice to the menu bar while he or she was visually "painting" the interface, he or she cannot return to the application generator to visually add this to the application program once the generated code has been modified by the developer user. Quite simply, conventional application generation tools do not understand the modifications added by the developer user. In other words, conventional application generation tools are very adept at generating the boilerplate code which is necessary for creating application programs; they are not adept, however, at understanding changes made to that boilerplate code once the user has begun editing the shell program for converting it into a "real" application program.

What is needed are system and methods for bi-directional application generation--that is, visual code generation tools which generate a source file, allow a user to edit the file with a text editor, then return to the visual code generation tool to further edit the form visually. More particularly, such a system should provide the developer with the ability to use both visual and text editing techniques interchangeably--switching at will. The present invention fulfills this and other needs.

SUMMARY OF THE INVENTION

The present invention comprises a development system with visual designer tools (Designers) for generating and modifying program code. During system operation, a user employs the Designers to visually create an application program and generate a source file. The user can proceed to edit the file with a text editor and then return to the Designers at any time to edit the form visually. Each Designer is a bi-directional or "two-way" tool: the user can modify a form either visually with a Designer, or by editing the generated code in a source (text) file with a text editor. The user can use both techniques interchangeably--switching at will. All changes which occur in Designers are reflected in the generated code and vice versa.

Providing bi-directional code generation requires a whole new approach to the process of creating programs. Bi-directional code generation requires a language representation which is easily understood by the designer module (which is responsible for visual design) yet also easily understood by the language processor or compiler (which is responsible for generating the final program by compiling the source code files). According to the present invention, language representation which supports bi-directional code generation is provided in the design of the objects themselves which are employed in programs. In other words, the approach to implementing bi-directional code generation is not to change the designer or compiler, therefore, but instead to change the basic nature of the objects themselves in the system.

According to the present invention, a communication path is adopted which "runs" all operations through the objects themselves. Although Designers appear to be operating on the objects of a visual form, they are, in fact, instead operating directly on the objects themselves. When the user adds objects to a form, he or she is given the illusion of being able to add objects directly to the form. What is happening instead is that the system, in response to these user inputs, is building objects in the background (i.e., in-memory program objects). The side effect of building those objects is that display methods of those objects are invoked for supporting an on-screen representation of those objects in the design session. The effect of operating directly on the object is that modifications to the objects manifest any changes to the objects themselves. Thus, a design session is simply one view of the objects, while run time execution of the underlying program (form) is another view of the objects. The source file generated for storing the program is yet just another view of the objects.

After the user has completed visual design of the objects, a collection of objects has been created. Each object includes methods which support streaming the object itself to disk. When a user saves a form during a design session, the system sends a message "stream yourself" to the objects. In conjunction with a Streamer object, the objects operate to stream themselves to a source file. The source file may be compiled by a compiler and executed by the system. When the user wishes to further modify the form visually, the source file (i.e., a collection of objects which were streamed out) is again run for reinstantiating those objects. The result is that a form appears on screen. In design mode, however, after the objects begin execution, they are additionally instructed to enter their design state (i.e., "design yourself").

BRIEF DESCRIPTION OF THE DRAWINGS

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 subsystem for controlling the operation of the computer system of FIG. 1A.

FIG. 1C is a bitmap screen shot illustrating a preferred graphical user interface (GUI) of the software subsystem of FIG. 1B.

FIG. 2A is a bitmap screen shot illustrating a preferred interface of the system of the present invention for developing application programs.

FIGS. 2B-C are bitmap screen shots illustrating use of the interface for creating a new form.

FIGS. 3A-F are bitmap screen shots illustrating a Form Designer of the present invention and accompanying tools (Property Inspector, Control Palette, and Procedure Editor).

FIG. 4A is diagram illustrating basic layout of a generated source file (dBASE .WFM file in a preferred embodiment).

FIG. 4B is a diagram illustrating basic layout of a generated source file for saving menu information.

FIG. 5 is a block diagram illustrating an overview of the development system of the present invention.

FIG. 6A is a diagram illustrating a high-level view of the source file format employed in the system of the present invention.

FIG. 6B is a diagram illustrating the relationship between visually designing a form, running the form, and then again visually designing the form.

FIG. 7 is a diagram illustrating a property table or grid employed in the system of the present invention.

FIG. 8 is a block diagram illustrating the operation of an object streaming itself to a source file.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

System Components

The present 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 disk). Processor 101 includes or is coupled to a cache memory 109 for storing frequently accessed information; memory 109 may be an on-chip cache or external cache (as shown). 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.

Illustrated in FIG. 1B, a computer software system 120 is provided for programming and operating the computer system 100. Software system 120, which is stored in system memory 102 and on disk memory 107, includes a kernel or operating system 150, a windows shell 145, and a Database Management System (DBMS) Development System 130. OS 150 is the executive or supervisor for the system 100, directing both task management and data management. DBMS Development System 130, on the other hand, includes a software subsystem for storing, retrieving, and manipulating information in database tables, and for developing application programs (e.g., programs 125). Under the command of DBMS Development System 130, the system 100 receives user commands and data through user interface 160. The interface 160 includes a command editor for processing system information, as described in further detail below. Additional application programs, such as DML (Data Manipulation Language) command programs 125 (for further controlling the operation of DBMS 130) or windows application software 140, may be "loaded" (i.e., transferred from storage 107 into memory 102) for execution by the system 100.

In a preferred embodiment, the system 100 includes an IBM-compatible personal computer, available from a variety of vendors (including IBM of Armonk, N.Y.). Operating system 150 includes MS-DOS, and Windows shell 145 is Microsoft.RTM. Windows; both are available from Microsoft Corporation of Redmond, Wash. DBMS Development System 130 preferably includes Visual dBASE.RTM. DBMS (available from Borland International of Scotts Valley, Calif.). The DBMS Development System 130 also includes two-way design tools, which are described in further detail below. If desired, other operating systems and/or DBMSs (or alternative configurations thereof) may be employed in accordance with the principles of the present invention.

Interface

A. Introduction

The following description will focus on the presently preferred embodiments of the present invention, which are embodied in a database development system operative in the Microsoft.RTM. Windows environment. The present invention, however, is not limited to any particular application or any particular 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 electronic spreadsheet systems, wordprocessors, 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.

In a preferred embodiment, the system 100 includes as the interface 160 a windowing interface or work space 161, as shown in FIG. 1C. Window 161 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 161 is a menu bar 170 with a plurality of user-command choices, each of which may invoke additional submenus and software tools for use with application objects. Window 161 includes a client area 180 for displaying and manipulating screen objects, such as graphic object 181 and text object 182. In essence, the client area is a work space or viewport for the user to interact with data objects which reside within the computer system 100.

Windowing interface 161 includes a screen cursor or pointer 185 for selecting and otherwise invoking screen objects of interest. In response to user movement signals from the pointing device 105, the cursor 185 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 161 may be closed, resized, or scrolled by "clicking" (selecting) screen components 172, 174/5, and 177/8, respectively.

In a preferred embodiment, screen cursor 185 is controlled with a mouse device. Single-button, double-button, or triple-button mouse devices are available from a variety of vendors, including Apple Computer of Cupertino, Calif., Microsoft Corporation of Redmond, Wash., and Logitech Corporation of Fremont, Calif., respectively. More preferably, screen cursor control device 105 is a two-button mouse device, including both right and left "mouse buttons."

Programming techniques and operations for mouse devices are well documented in the programming and hardware literature; see e.g., Microsoft Mouse Programmer's Reference, Microsoft Press, 1989. The general construction and operation of a GUI event-driven system, such as Windows, is also known in the art; see, e.g., Petzold, C., Programming Windows, Second Edition, Microsoft Press, 1990. The disclosures of each are hereby incorporated by reference.

B. User Interface

1. Development System Desktop

Shown in FIG. 2A, a preferred interface for the Database Development System 130 of the present invention will now be described. The interface comprises a Desktop 200 having a main menu 201, a toolbar 202, a File Viewer or "Navigator" Window 203, a Command Window 220, a Command Results Window 230, and a status line 206. The menu bar 201 displays and invokes, in response to user inputs, a main level of user commands. Menu bar 201 also invokes additional pulldown menus, as is known in windowing applications. The Desktop 200, File Viewer 203, Command Window 204, and Command Results Window 230 all have control-menu boxes, and minimize and maximize buttons, as is known in windowing applications. Status line 206 indicates the current status of the development system including, for example, the name of a database table being processed.

The toolbar 202 comprises a row of tool icon buttons which provide a quick way for users to choose commonly-used menu commands or properties. The toolbar is a dynamic object in the sense that only the tools available in a given context are displayed. For instance, the editing tool icons will not appear unless the user is editing.

The File Viewer 203 includes edit boxes for entering file names and paths in order to display tables, forms, program source code, and the like. The user can enter a particular file name or, alternatively, select from a list of files that meet some user-supplied criterion. For example, by clicking on the "Tables" icon, the File Viewer will display all table names (e.g., files with extension .DBF or .DB) in the current directory. Clicking on a particular target table name will then open and display that table. Other selectable file types are All, Queries, Forms, Reports, Labels, Programs, Images, Sounds, and Catalogs. These selections are also available via user commands accessible from the main menu bar 201.

2. Command Interface

Commands for directing operation of the system are entered in the Command Window 220, which is a scrollable edit window that accepts user input for creating a sequence of commands. Commands can be any sequence of expressions, assignments, function calls, and the like, as mandated by a target language. In an exemplary embodiment, the target language is the dBASE.RTM. Language for manipulating database information. To aid the user in command entry, immediate feedback of the result (or "return value") of each command entered in the Command Window 220 is displayed concurrently in the Command Results Window 230. The Command Results Window 230 is a scrollable, edit-style window which typically appears below the Command Window. The Command Window 220 can also be moved and resized, or maximized to the size of the Desktop, all without affecting the basic editing methods.

Program Development

A. Form Designer

Although the system may be operated interactively using the Command Window 220, users will typically create application programs for operating the system. Application programs are created using a form-based visual programming environment or "Form Designer." To invoke the Form Designer, the user selects a "Form" menu choice 240 from the menu bar (i.e., menu bar 201 of FIG. 2A), as shown in FIG. 2B. Before displaying the Form Designer, the system first displays a Form Expert 250, as shown in FIG. 2C. Here, the user can request assistance with creating a form, or choose to simply start with a blank form. For the example at hand, the user will simply choose "blank form" 251, thereby bypassing the Form Expert.

Next, the system displays at the interface a Form Designer 300, as shown in FIG. 3A. As illustrated, when the user creates a form with the Form Designer, he or she is presented with a design surface which includes an empty form window (e.g., form 310). The Form Designer presents the user with a design surface composed of a window, a grid, and rulers, thus serving as the background of the form. Here, the user can set the size of the form window, place controls on the design surface in the positions he or she wants them to appear on the form, set the sizes of the controls, and specify the visual layers of the controls, along with the tabbing order of those controls that can receive focus. Into the empty form, the user can select and place objects, such as entry fields, list boxes, check boxes, and the like. Thus designing forms is as simple as arranging objects in a window. The objects can be manipulated using conventional graphical user interface methodology, including selecting, moving, sizing, and the like. When design is complete, the form may be "run." When running, forms are application programs: they display messages and data, respond to user input, and provide interactive controls such as menus, pushbuttons, and scroll bars. Using forms, therefore, the user can build a simple data entry application (e.g., based on one or more database tables), or build a complete user interface for a complex application.

The user creates the basic user interface by selecting controls from a Control Palette 330 and placing them on the form. The Control Palette has two pages: Standard and Custom. The standard controls include control types of pushbutton, radio button, check box, line, text object, entry field, OLE object, combo box, list box, and the like. Custom controls can be custom dBASE controls (which have a .CC file-name extension) or custom Microsoft Visual Basic (.VBX) controls. To add a control to the form, the user selects clicks on the control on the palette to select it. When the pointer passes over the design surface, the pointer turns into cross hairs. The user clicks and drags the pointer across the design surface until the control is the desired size; or the user can click the design surface (without dragging) to add a control in a default size. FIG. 3B illustrates the placement of a pushbutton 311.

The user sets the properties of the components or objects on the form to customize their characteristics and behavior. In a preferred embodiment, this is done interactively using Properties Dialog or Object Inspector 320, shown in FIG. 3A. An Object Inspector is a window that displays the properties, events, and methods for the current object. The properties, events, and methods are displayed on separate tabbed pages; the user clicks the tab at the bottom of the inspector to display the page whose name is on the tab. "Properties" or attributes define an object's characteristics, such as its size, location, and color. In essence, properties are memory variables that contain data about an object. In FIG. 3B, the properties for the pushbutton 311, for instance, are shown in the Inspector Dialog at 312.

"Events" or event properties determine an object's behavior--that is, how it responds to events, such as mouse clicks and key strokes. The user can specify what happens when an event occurs by linking a "code block" or a procedure to the relevant event property. This code creates an event handler. In other words, an event handler is a subroutine that executes automatically when a particular event occurs. In FIG. 3C, the event properties for the pushbutton 311, for instance, are shown in the Inspector Dialog at 313.

"Methods" are procedures that are associated with a particular object. They determine what actions can be performed on objects, for example, releasing objects from memory, giving focus to objects, moving objects, or the like. In FIG. 3D, the properties for the pushbutton 311, for instance, are shown in the Inspector Dialog at 314.

Upon invoking a Procedure Editor 340, as shown in FIG. 3E, the user writes event handlers for forms and their controls. Using the Procedure Editor and its related tools (including Link Event to Procedure and Edit Event dialog boxes), the user writes and structures the code that defines the form and its behavior. In particular, the user uses them to: (1) write methods for the form; (2) write comments at the beginning of the program; (3) write code to be executed before the form is constructed (typically, to declare static variables and public variables); (4) create event handlers by linking procedures and methods to events; and (5) write general procedures that can be referenced from other sections in the code.

If the form already has methods upon invoking the Procedure Editor, the first method in the combo box appears in the Text Editor window of the Procedure Editor. If the form does not have methods, the Procedure Editor displays comments and/or code in the header section of the form code. To open the Procedure Editor and create a new method, the user does the following. In the Object Inspector, the user clicks the Events page, chooses an event, then clicks the Tool button to the right of the text box. This process creates a new method and links it to the selected event. The Procedure Editor opens (or it becomes active if it is already open). The Text Editor window contains a PROCEDURE statement, with a suggested name for the new method. The user can write a new procedure to link to the current event in the Object Inspector. Alternatively, the user can write a new procedure, then manually link it to an event through an Link Event dialog box.

Finally, the user can user Menu Designer 350, shown in FIG. 3F, to create a complete menu system for a form, including a menu bar, pull-down menus, and cascading menus. Like the Form Designer, the Menu Designer is a tool for placing objects in a window. It uses the Object Inspector to set properties and the Procedure Editor to write event handlers. Since a menu system is made up of only one kind of object--a Menu object--there is no Control Palette for the Menu Designer. Instead, the user creates menu objects by positioning the insertion point and typing the menu prompt. The user creates a menu system by building a hierarchy of menu objects from left to right, top to bottom. To add a menu object, the user directs the insertion point to where the user wants the object to appear and then enters the menu text. In a conventional manner, the user can use the Menu Designer to add and delete Menu Items, specify "Shortcut" and "Mnemonic" keystrokes, and assign actions to Menu Objects.

Upon completion of the from, the user switches the form from "design view" to "run view"--that is, the form at runtime. When a user "runs" the form, the form and its controls become active. If the form is associated with data (e.g., records in a table), that data can be viewed and/or edited in the form by an end user. Typically, end users will operate the form using menus and other controls which were included by the designing user for controlling basic operations of the form. To run a form at any time, the user selects the screen button 371 (equivalent to menu item View.vertline.Form), shown in FIG. 3E. The user may switch back to design mode by selecting screen button 372 (equivalent to menu command View.vertline.Form Design).

Additional description of the Form Designer and its use may be found in dBASE.RTM. for Windows, User's Guide, Programmer's Guide, and Language Reference, all available from Borland International, Inc. of Scotts Valley, Calif. (Part No. DBS1150WW41000). The disclosures of each of the foregoing are hereby incorporated by reference.

B. Code Generation with Two-Way Tools

When the user instructs the system to save a form, the Designers generate source code (in a preferred embodiment, dBASE.RTM. language code) that defines the form and its objects. Specifically, the code defines the object's properties and any event-handling code which the user attached to the form and its objects. In an exemplary embodiment, the system saves the form as a text file with a default extension of .WFM (Windows ForM).

The Form Designer and the Menu Designer both generate code based on the forms and menus the user lays out visually. For most projects, the user does not need to edit the generated code. However, some projects might require the user to adapt or add to the generated code for use in the application. Since both the Form Designer and Menu Designer are "two-way tools," the user can modify the generated code with a text editor, then reload it into the Designers. This feature lets the user develop programs his or her own way, laying out objects visually, refining the code, and returning to the Designers as needed.

FIG. 4A illustrates exemplary code generated by the Form Designer. As shown in the figure, a source (.WFM) file 400 generated by the Form Designer contains three main sections. Program Header 410 comes first. In the Procedure Editor, the user can enter the program header by selecting Header from the editor's combo box (shown in FIG. 3E). The header can contain any code the user wants to execute before creating the form. Typically, the header includes comments, preprocessor directives (for declaring constants or inserting include files), and variable declarations. This is code that executes before the form is constructed at run time.

The Class Declaration 420 follows the header. Specifically, this comprises a CLASS . . . ENDCLASS definition setting forth properties and method declarations for the form. It makes up the main body of the code. The Form Designer generates most of the subclasses for the user, including the property settings for the form window and the definitions for each control. The user can enter event-handling procedures using the Procedure Editor.

The third part or general section 340 of the file comprises any code which follows the form's CLASS declaration. This section generally includes procedures that are referenced by event handlers. Declarations for "Supporting Procedures" follow the class declaration. Supporting Procedures are any procedures called by event-handling procedures. In the Procedure Editor, the user enters Supporting Procedures by selecting "General" from the Procedure Editor combo box.

FIG. 4B shows the code created by the Menu Designer. The Menu Designer saves the code to a file with a .MNU extension. The user can link a .MNU file to a form by specifying the .MNU file in the form's MenuFile property. In a manner similar to that previously described, menu source file 460 includes a Header 470 and a Class Declaration 480. Using the Menu Designer, the user can create a complete menu system for a form, including a menu bar, pulldown menus, and cascading menus. Each menu object provide built-in properties for specifying shortcut keys, checked items, grayed items, and other menu features. The user can attach code directly to menu objects through the OnClick event, making it easy to reuse all or part of a menu in another form. The model for building menus is based on the hierarchy and containership of menu objects, not the kind of menu. The user does not explicitly define menu bars, pulldown menus, or cascading menus. Instead, the user builds a hierarchy of menu objects, where each menu object contains another menu object or executes an action. Just as a form contains controls, menu objects contain other menu objects. The system automatically determines where menus appear based on their level in the hierarchy. The user's own input (e.g., "File") is used to name object references.

Internal Operation

A. Design Considerations

Ultimately, a system must store a representation of the objects being designed visually in a file, so that they may be re-designed at a later time. In Borland's Resource Workshop.RTM., for instance, visually created objects are stored in a Microsoft Windows-compatible resource script format (i.e., .RC file). Traditionally, application design tools have stored this information in a format that is best suited for the tool. Although these tools include the capability of outputting code to a text file which can be edited, such text files are a very different form than the preferred form which these tools have traditionally stored development information. Perhaps the easiest approach to storing representations of visually-designed objects is to simply dump internal data structures of the tool to disk. Although suitable for one-way code generation, such an approach is poorly suited to bi-directional code generation.

B. Object-Centric Approach

Providing bi-directional code generation requires a whole new approach to the process of creating programs. Bi-directional code generation requires a language representation which is easily understood by the designer module (which is responsible for visual design) yet also easily understood by the language processor or compiler (which is responsible for generating the final program by compiling the source code files). According to the present invention, language representation which supports bi-directional code generation is provided in the design of the objects themselves which are employed in programs.

FIG. 5 illustrates an overview of the approach. As shown, Development System 500 includes Objects 510. At this point, the objects may be viewed in a conventional sense in that they include data members and methods which operate on those data members; inheritance from one object class to another is also supported in a conventional manner. Of particular interest to the present invention are the visual objects--that is, objects which include an on-screen representation (e.g., pushbutton object which is displayed as a button on-screen). Although visual objects are of interest to the present invention, the Development System 500 does not treat them differently from non-visual objects. Instead, the Development System simply manages objects, some of which include the capability of being designed visually (i.e., include methods which support visual design). The approach to implementing bi-directional code generation is not to change the designer or compiler, therefore, but instead to change the basic nature of the objects themselves in the system.

Consider a form, for instance. The form consists of some collection of objects. The simplest case is just a single form object--that is, the form by itself. The form object is constructed in the system of the present invention so that it knows how to design itself--that is, it includes methods which support a user session of the form in the Form Designer. Further, the Form Object also includes methods which support streaming of the object itself to a source file (e.g., .WFM source file).

The difficulty which presents itself is, therefore, what is the "communication path" for how a user designs objects. According to the present invention, the communication path adopted is to "run" all operations through the objects themselves. To design or modify the program visually, therefore, the Objects 510 are passed to Designer 520 which, in turn, launches a Design Session 530. The Design Session 530 provides a Visual Form 531 and a plurality of Design Tools 533 for manipulating the form. The Design Session, therefore, provides a visual representation of how the form looks at run time and includes the objects that are on the form (which at this point can be modified by the user). Tools 533 comprise the tools which operate on the objects in design mode, such as the Object Inspector (Object Inspector 320 of FIG. 3A), Control Palette (Control Palette 330 of FIG. 3A), and Procedure Editor (Procedure Editor 340 of FIG. 3E). Although the Tools 533 appear to be operating on the objects of Visual Form 531, they are, in fact, instead operating directly on the Objects 510, as indicated by Dash Line 535. The effect of operating directly on the object at 510 is that modifications to the objects manifest any changes to the objects themselves at 510.

Although the Tools 533 appear to the user to be operating on the objects of Visual Form 531, this in fact is not the case. Quite simply, direct interaction between the Tools 533 and the Visual Form 531 does not occur (as indicated at 537). In other words, although the Tools 533 appear to be operating visually on objects of Visual Form 531, they are actually always operating directly on the in-memory Objects 510 (as indicated at 535). The net result is that all changes to the objects are maintained at the Objects 510. If, when designing an object, the user changes its position on screen, that action leads to a message being sent from the Tools 533 directly to the Objects 510. That message is acted upon by a corresponding message handler (i.e., an "update position" handler), which, as part of its responsibility, causes updating of the on-screen representation of that object at Visual Form 531. In this fashion, the Design Session is merely "one view" of the Objects 510.

When the user brought up the empty form 310 in FIG. 3A, and then added pushbutton object 311 in FIG. 3B, he or she is given the illusion of being able to add objects directly to the Form. What is happening instead is that the system, in response to these user inputs, is building objects in the background (i.e., in-memory Program Objects 510). The side effect of building those Objects 510 is that display methods of those objects are invoked for supporting an on-screen representation of those objects at the Design Session 530.

After the user has completed visual design of the objects, a collection of objects (i.e., Objects 510) has been created. As previously mentioned, each object includes methods which support streaming the object itself to disk. After building a collection of objects, therefore, it is a straightforward matter for the objects to stream themselves to a source file on disk. When a user saves a form during a design session, the system sends a message "stream yourself" to the Objects 510. In conjunction with Streamer 540, the objects operate to stream themselves to a Source File 550. The Source File is compiled by the Compiler 560 and then executed by the system. When the user wishes to further modify the form visually, the Source File 550 (i.e., a collection of objects which were streamed out) is executed for re-instantiating those objects. The result is that a form appears on screen. In design mode, however, after the objects begin execution, they are instructed to enter their design state.

As illustrated in FIG. 6A, each Source File 600 includes two specific parts. The bottom part of the file, shown at 620, comprises a class definition. The class definition embodies all of the properties and behaviors associated with the form and its objects. The top part of the file, shown at 610, comprises instantiation code. This section is generally short, comprising a line for instantiating the form (FORM.NEW) and a line for opening the form (FORM.OPEN). In this manner, the Source File is a self-contained file for both running and designing the program.

FIG. 6B illustrates the general process of running the File 600. When a request is made to run a form, it is compiled and then run. Because of the Instantiation Code 610 (i.e., which says, in effect, create an instance and run it), a form is opened. If the path chosen by the user is to design a form which was previously saved, then the foregoing steps are followed, plus one additional step. That additional step is posting a message to the form and its objects to "design yourself." Internally, this instructs the form to enter into its design state.

Streaming is facilitated by the way objects are represented internally. In a preferred embodiment, object properties are represented internally as a series of name/value pairs, stored in a property table. This is implemented in a generic manner so that the system does not expect the object to be of a particular type. Specifically, objects in the system include methods for "revealing" themselves (i.e., surfacing its properties). In this manner, the Streamer object can ask objects about themselves and then write out to disk a textual representation of that information. "Streaming" in this context is the task of saving the state of an object to some representation in a file which may be recovered later. Instead of writing out the internal (in-memory) representations of data objects, therefore, the system of the present invention writes out the code which is necessary to recreate those in-memory data structures.

In addition to streaming, the ability to query objects in a generic way is also used by the design tools. The Property Inspector, for instance, interacts with objects in the exact same manner as the Streamer. When a Property Inspector lists the properties for an object, it appears to have knowledge about that object. The Object Inspector, in fact, has no knowledge about that object or any other objects, but, instead, asks the object generic questions: who are you? what are you like? what tools do you require? The approach adopted by the system of the present invention, therefore, is to employ a generic communication path whereby any module which needs to do something with an object talks to that object in a generic manner.

As an example of querying an object for determining whether it supports an interface, consider the following:

__________________________________________________________________________ 1: // Typical call to check interface support 2: IFileDependency *pFileDependency 3: = SUPPORTS(pObjSupports,IFileDependency); 4: // If interface is support 5: // invoke relevant functionality 6: if (pFileDependency != NULL) { 7: int count = pFileDependency->FileDependencyGetFileCount( ); 8: CString fileName; 9: for (int i = 0; i < count; ++i) { 10: pFileDependency->FileDependencyGetFileName(0, fileName); 11: // printf("depend (%s).backslash.n",fileName.GetBuffer(0)); 12: } 13: 14: } __________________________________________________________________________

As shown at line 2, a call is made to SUPPORTS (a macro) for determining whether the object supports a particular interface, here IFileDependency. That interface knows how to get a list of dependent files. Accordingly, if the interface is supported, the dependent files are retrieved (lines 4-14). If the interface is not supported, on the other hand, no request is made to get the dependency files. The pObjSupports member is a pointer to an object which can be queried, for determining what interfaces it supports. This is in effect a pointer to a (small) portion of the current object (e.g., one being streamed). The SUPPORTS macro invokes a function call to a Supports method of the object, the call requesting its dispatch interface, a Dispatcher. The Dispatcher, in turn, knows about all the names and values of a given object--the properties and values for an object. An Enumerator is also provided which simply allows one to enumerate the properties of an object one at a time. Thus the Dispatcher has a property table; the Enumerator allows each property to be retrieved one at a time (i.e., expose properties sequentially from the Dispatcher).

In the system there exist always a Dispatcher associated with every object. The Dispatcher has the ability at any time to reconstruct in text form the name and (effective) value for properties of the object. Suppose, for instance, that the user sets the property of color to "red" for a form in the Form Designer. Internally, the Dispatcher sends a message to the Form Object to set the property color to the value of red. Although the property is set to a particular value (e.g., integer or bit pattern) corresponding to the object's internal representation of red, the object also "remembers" the text form for the property (i.e., "red"). The object completes the process by effecting any other required side effects, such as repainting a visual representation of the object on screen. Later on, when the Dispatcher asks the object about that property (via the Enumerator object), the object will respond with the textual representation of the current value for that property (i.e., "red"). Therefore, in addition to objects maintaining their own internal representations of properties (i.e., storing a particular integer for the color red), the objects also maintain textual representations of property values which can be return to the Dispatcher, upon request.

FIG. 7 illustrates a Property Table 700--the Dispatcher's view of an object (here, a pushbutton object). The Property Table or grid comprises a Name field 701, a Value field 703, a Pointer-to-Member Function field 705, and a Flags field 707. Because the Dispatcher's purpose is to dispatch the setting and getting of properties, it employs the pointer-to-member function to invoke the appropriate function for setting and getting the relevant property. Using this pointer, the Dispatcher can make a call to the appropriate member function, pass a property value, and specify whether it is getting or setting the property.

With an understanding of the Dispatcher and the Enumerator, the task of streaming an object will be further described. As shown in FIG. 8, Object 810, such as a pushbutton object, can be viewed as two parts: a Core 811 and a Dispatcher 815. The Core 811 comprises the core functionality needed to make the object work, such as the functionality required to make a pushbutton object work at run time. The Dispatcher 815, previously described, is responsible for getting and setting the properties of an object. At the time when it is desired to stream an object, a third object is created: Enumerator 817. The Enumerator 817 communicates with the Dispatcher 815 to enumerate all of the properties of the object. Additionally, a Streamer 819 is created. The Streamer 819 is passed a container (i.e., form) and then, in a recursive manner, streams all containees to a source file. At the level of the actual object, the streamer is enumerating the particular properties of the object.

Attached hereto is an Appendix A containing C++ source code listings, which provide further description. A suitable compiler for compiling and linking C++ code is available from Borland International. Also attached hereto is an Appendix B containing a user manuals and additional reference materials providing further description of the present invention.

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##

* * * * *

---