Application Management System

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 file or records, but otherwise reserves all copyright rights whatsoever.

The invention relates to application programming systems for computers, and particularly to a system for achieving a common user access (CUA) interface with a computer operating environment throughout multiple applications utilizing dynamically linked, shared code.

In order to program a computer effectively, a computer programmer must master a number of commands, application program interfaces (API's), and data structures. This usually requires a large investment of time learning specific techniques to code common basic functions for a specific operating environment. These common basic functions include presentation of data graphically on the screen, presentation of data on the printer, and storage and retrieval of data via a database management system. The requirement for generating and testing primitive code to build these common basic functions reduces the productivity of the programmer whose primary focus is to develop the specific functionality of the application.

Another important aspect of programming is consistency in the user interface where multiple applications are developed for use in a particular operating environment. A graphic user interface (GUI) is a means through which a computer system communicates with users. The GUI provides an assortment of controls or graphic user interface (GUI) components that are available for use by applications in the presentation and gathering of data. A GUI component is a graphic element that is used to display and accept information from the user. An application may define additional user interface components. Application defined components characteristically behave similar to GUI components.. Common user access (CUA) is the definition of GUI components that should be the same across all applications. The definition is based on a set of generally accepted user interface design principles. It is optimized for ease of use and encourages learning by exploring. CUA is helpful to the user because once the user learns the procedures to implement commands for achieving particular results in one application, he can expect the same procedures to apply in other applications.

In a programming environment, the framework, interaction techniques and other characteristics for defining a CUA interface are determined by procedural code written by the application programmer to implement various responses to user actions. Differences in coding techniques and style from one programmer to the next make it difficult to insure consistency in a CUA. In addition, even if CUA is accomplished, the procedural codes developed by one programmer will differ from another thereby requiring individual testing of the same characteristic of the CUA in multiple programs.

Consistency in coding of CUA procedural code and common basic functions is therefore desirable to ensure thorough testing and quality control where multiple program authors with individualized coding styles each contribute to a package of applications. In order to achieve this consistency, procedural codes to maintain a CUA may be coded one time, then shared between multiple applications. Similarly, many common basic functions of each application may be coded once and shared. This increases the productivity of the programmer and also avoids duplication of effort in programming. In the past, sharing of common basic functions has been done by the use of code libraries. Code libraries have the advantage that a piece of code can be developed, tested and maintained "outside" of the application program. The program then links to this library and at link time the code is placed into the application's executable file. The disadvantage of this method is that all the programs that require this code will have it contained in their executable file. This increases the size of each application file and may present a problem where multiple applications are desired for use on computers with limited disk and/or memory space.

Runtime loadable control modules have been developed to provide shared code that can be used by a variety of applications. The shared code contains routines to aid the programmer in code development. These modules generally deal with one specific area of programming. One such runtime loadable control module is a database management system module that handles the reading and writing of data in a record oriented input/output method. Another runtime loadable control module is an operating environment module that provides the GUI of the particular operating environment for interaction with the user via the computer keyboard, pointing device, screen or printer. For example, in the Tandy DeskMate operating environment, the database management system module is referred to as the DeskMate Database Management System (DMDB) and the operating environment GUI module is referred to as the DeskMate Core Services Resource (CSR).

The advantage of using runtime loadable control modules is that they allow for the storage of code in one location that may be accessed and shared among multiple applications without the necessity for duplicating the code in each application program. However, runtime loadable control modules traditionally do not incorporate procedural code that wholly contains a CUA. Such code governing reactions between components on a screen in response to user action or input tends to be application specific.

In addition, runtime loadable control modules associated with the respective GUI and database management systems have historically been disjoint. Each of the GUI and database management systems of an operating environment are defined through separate and distinct API and data structures. In order to utilize both the GUI and database management systems, an application must contain code that separately manages each of the GUI and database management system's unrelated data structures. The application must also contain code to translate data from one set of data structures to the other set of data structures. The application must further contain code that defines the relationship between data that is stored on the disk and data presented to the user via the GUI common basic functions.

The invention recognizes the need for maintaining common user access (CUA) through the use of shared procedural code where multiple applications written by various programmers are implemented in a particular operating environment. The invention also recognizes a need for integrating the GUI and database management systems of an operating environment, each having their own unique API's and data structures. The result is greater efficiency and productivity in application programming.

According to the invention, an application management system provides an operating environment for multiple applications using a common user access interface in a computer system. Data is defined in each application for describing the appearance and operation of the application. A module is linked to the applications. The module is used by the applications to initialize the data in the applications, present a display screen defined by the data, process user input events in accordance with the operation defined by the data and close the application. The module may be run time loadable.

The invention eliminates the need to write procedural code in each application to maintain CUA. The invention also eliminates the need to write code to perform the functions of database management (add, delete, update, read a record), the GUI functions (display data, print data, respond to user input) and the data translation algorithms between the GUI and database management systems. The invention increases the programmer's productivity by optimizing the programmer's use of development time and reducing test and debug time.

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

FIG. 2 is a block diagram of a computer software system used in the preferred embodiment.

FIG. 3 is a block diagram of a prior art computer software system showing the elements of an application and how the application interacts with the operating environment .

FIG. 4 illustrates a computer screen display showing common user access interface components.

FIG. 5 is a block diagram showing in greater detail a computer software system used in the preferred embodiment.

FIG. 6 is a block diagram showing the computer architecture of the application control module (ACM) of the computer software system used in the preferred embodiment.

FIG. 7 is a flow chart of the general methods of the computer software system used in the preferred embodiment.

FIG. 8 is a flow chart of the methods of the INIT function.

FIG. 9 is a flow chart of the methods of the RUN function.

FIG. 10 is a flow chart of the methods of the Action Interpreter function.

FIGS. 11A and 11B are flow charts of the methods of the Event Interpreter function.

FIG. 12 is a flow chart of the methods of component reactions of the command dispatcher.

FIG. 13 is a flow chart of the methods of the END function.

Referring to FIG. 1 of the drawings, the preferred embodiment of the invention is implemented on a computer system 100 having a central processor 102, a system memory 104, a display 106, a printer 108, a keyboard 110, a pointing device 112, a disk storage 114, an I/O controller 116, and interconnecting means 118, such as a system bus. In the preferred embodiment a Tandy 1000 series computer manufactured by Tandy Corporation of Ft. Worth, Tex. is used as the system 100.

Referring to FIG. 2, a computer software system 200 is shown for programming one or more computer applications 202 to be implemented by the computer system 100 of FIG. 1. Software system 200 is stored in the system memory 104, and on the disk storage 114. System 200 programs the central processor 102 to display a graphic user interface (GUI) on the display 106. An application control module 204, as will be discussed subsequently in detail, is implemented in an operating environment 206. The operating environment 206 provides a software user interface 208 between a user 210, the computer application 202, and an operating system 212. In the preferred embodiment, the operating environment 206 is the Tandy DeskMate environment. Detail regarding the DeskMate environment is contained in the DeskMate Development System Manual, incorporated herein by reference and available from Tandy Corporation of Ft. Worth, Tex. It is understood that all function calls referenced throughout this specification are part of DeskMate. It will be apparent, however, that one of ordinary skill in the art, informed by this specification, could implement the invention in other operating environments.

As will be described further below, the application control module 204 enables programmers to develop applications 202 that conform to a specific CUA by defining data structures rather than by writing procedural code. The application programmers use shared code provided by the module 204 defining the CUA interface and can concentrate on developing the logic of the particular application.

In order to understand the invention, FIG. 3 depicts a prior art software system 300 to show the development process normally required for writing an application 302 in an operating environment 304.

The application 302 comprises procedural code 306, a GUI API 308, a database management API 310, and data conversion code 312. While not shown, it is understood that the application 302 also includes code for performing the functions specific to that application. The operating environment 304 (DeskMate, for example) includes operating environment GUI modules 314 and a database management system (DBMS) module 316. The GUI modules 314 are run time loadable control modules and are accessed via the GUI API 308 contained in the application 302. The GUI modules 314 are for programming a software user interface 318 which interacts with a user 210. The DBMS module 316 is accessed via the database management system API 310 in the application 302 and performs all record oriented file input/output (I/O) with a disk storage 114.

The GUI API 308 provides functions to control the video display 106, printer 108, pointing device 112, communications ports (not shown) and other devices. It also provides a method for the application 302 to receive user input through additional function calls. The application 302 is responsible for evaluating each user input or action and determining the appropriate reaction.

The database management API 310 provides record level access into files. The application 302 provides the definition of records in a file, and the database management API 310 provides functions such as retrieving, adding, updating, deleting, sorting, and searching of records.

Referring also to FIG. 4, the application 302 designs the presentation of data to the user on an example screen 400 through the use of GUI components placed in particular locations on the screen. The GUI components include a listbox 402, a menubar 404, one or more editfields 406, push buttons 407, and one or more application defined components. The application defined components include, for example, a navigation bar 408. The navigation bar provides an easy method for the user to move between related applications. The list box 402 contains items 410a-410d from which the user can select one item. The editfields 406 include data which appears depending on which of the items 410a-410d in the list box have been selected. The selected item 410a is designated by highlighting the item in listbox 402. Graphic pictures 412 may also be displayed. A title line 414 is displayed at the top of the screen 400. While not shown, it is understood that other GUI components may be displayed such as scroll bars, radio buttons, check boxes or the like.

For example, the application 302 will build a list of items 410a-410d consisting of a single field from each of several records by calling the database management system 316. The application 302 will then place that list of fields into the listbox 402 and set selection to the first item 410a. The application will then read the record associated with the field selected 410a in the listbox and place that data in the editfields 406. The application 302 will then call the appropriate GUI functions 314 to display the listbox 402 and editfields 406 containing the new information.

The user will perform work by taking some action via the keyboard 110 or the pointing device 112. This action is interpreted by the application procedural code 306. The application procedural code 306 determines what the appropriate reaction is to that action. For example, the user may select a new item 410b, "Jewelry Box" in the listbox 402 by using the pointing device 112 or the arrow keys (not shown) of the keyboard 110. The application procedural code 306 reacts to this action by determining that the selected item in the listbox 402 has changed. The procedural code 306 determines the new data to be retrieved by identifying the selection stored in GUI, component data structures for the listbox 402. The GUI component data structures are described in detail in Appendix B. The procedural code 306 calls a function in the DBMS module 316 to retrieve the data associated with the new selection. After retrieving the data, the application data conversion code 312 converts the data from a DBMS data structure into the appropriate GUI component data structures (editfields 406, for example). The DBMS data structure is described in detail in Appendix A. The application 302 then makes the appropriate GUI function calls to display the new data.

The above method of handling GUI components and retrieving data from the DBMS module 316 in response to user input is a standard method by which applications interact with a user. Due to the different number of components and different types of data that may be required for each unique application 302, the code to implement this standard method is customized for each application. The different code in each application 302 makes it difficult to achieve a CUA interface across multiple applications and share similar code across multiple applications.

FIG. 5 shows in greater detail a software system 500 of the present invention for programming one or more applications 502 to run in an operating environment 504. Procedural code 506, a GUI API 508, a database management API 510 and data conversion code 512 are all included within the application control module 204. The operating environment 504 also includes operating environment GUI modules 514 and a DBMS module 516. The GUI modules 514 are runtime loadable control modules and are accessed via the GUI API 508. The GUI modules 514 are for programming a software user interface 518 which interacts with a user 210. The DBMS module 516 is accessed via the DBMS API 510 and performs all record oriented file I/O with a disk storage 114.

All of the above described elements are contained outside of the application 502 and otherwise function substantially the same as the corresponding elements described with reference to FIG. 3, with the exception of the procedural code 506 and the data conversion code 512. The procedural code 506 and the data conversion code 512 are generalized for access by multiple applications and do not need to be developed in each application. These modules are included in a separate application control module (ACM) 204 loadable by the application. This eliminates the need for the procedural code and data conversion code to be physically linked into each application.

The application 502 includes GUI component data structures 524, database data structures 526 and ACM data structures 528. The GUI component data structures 524 and the database data structures 526 are the same as those previously described and set forth in Appendices A and B. The ACM data structures are set forth in Appendix C.

An ACM API 530 is included in the application 502 and is used to pass data defined in the ACM data structures 528 to and from the application 502 and the ACM 204. The ACM data structures 528 describe to the ACM 204 the appearance and operation of the application 502. While not shown, it is understood that the application 502 also includes coding for performing the functions specific to that application excluding the procedural code for the execution of the application CUA.

Referring to FIGS. 4 and 5, a brief example will be described to explain the operation of the system 500. The application 502 passes data to the ACM 204 to describe that there is a listbox 402 and editfields 406 on the screen 400 for presenting data from the DBMS module 516. The ACM 204 will build a list containing the specified field from all database data (records) that match the specified query. The ACM 204 will convert the built list so it may be used by the listbox 402. A specified item in the listbox 402 will be highlighted to indicate selection. The data (record) corresponding to that selection will be read from the database management system 516. All fields read by the ACM 204 will be placed in the prescribed editfields 406 by means of the ACM data conversion code 512. The ACM 204 has initialized and now displays the listbox 402 and editfield 406 GUI component data structures. It is understood that the ACM will also display any requested graphic pictures 412, static strings, or icons.

The ACM 204 will wait for user input. When the ACM receives a return code from the GUI component (such as listbox 402 or editfield 406) the ACM will match that return code to a corresponding command defined by the application. The ACM 204 will execute that associated command. Accordingly, when a user selects a new item in a listbox, the ACM 204 will retrieve the corresponding data and display it in the appropriate editfields 406 without application intervention.

FIG. 6 depicts the overall architecture 600 of the application control module (ACM) 204. The ACM 204 provides multiple functions to the application 502 via the ACM API 530. A brief definition of the functions is as follows. INIT 602 (tm.sub.-- init) allows the application 502 to register with the ACM 204 and initialize its screen and data. DRAW 604 (tm.sub.-- draw) allows the application to request that the ACM 204 draw all or any portion of its screen. RUN 606 (tm.sub.-- run) waits for user input and invokes an action interpreter 610 and an event interpreter 612, discussed further below, for processing all user input until some action occurs that it doesn't know how to process, then it returns control to the application 502. COMMAND 608 (tm.sub.-- cmd) allows the application 502 to request that the ACM 204 perform a specific command. PRINT 614 (tm.sub.-- print) instructs the ACM 204 to print data. END 616 (tm.sub.-- end) causes the application 502 to notify the ACM 204 that it is terminating and any necessary cleanup by the ACM can occur.

The ACM 204 is based on a series of commands. A command is an instruction to a command dispatcher 618 to transform user action into procedural code to do the requested work. All of the ACM functions interact with the command dispatcher 618. The command dispatcher 618 invokes commands through a series of function calls to one or more handlers. The handlers include a screen handler 620, a component handler 622 and a data handler 624. The screen handler 618 and the component handler 620 interface with the GUI API 508 to achieve a CUA interface. The data handler 624 interfaces with the DBMS API 510 to retrieve and store data in the disk storage 114.

The action and event interpreters 610 and 612 make decisions as to what combination of commands are to be invoked based upon user action. The action interpreter 610 will process each component return code to determine if there is an associated command to be executed. This is detailed further in FIG. 10. The event interpreter 612, described further in FIGS. 11A and 11B, processes user input. The user input is translated into commands which are are executed through calls to the command dispatcher 618. Status information is reported to the application 502 as requested.

FIG. 7 illustrates how an application 502 would utilize the ACM 204 to perform most of the application's general processing.

The application 502 begins execution at step 700. At step 702, the application requests that the ACM 204 be loaded into system memory 104. Once loaded, the ACM 204 is dynamically linked or bound to the application. At the time that the ACM 204 is loaded into system memory, the operating environment GUI module 514 is bound to the ACM 204. Reference is made to the DeskMate Development, System manual for a further explanation of loading and binding to a module at runtime. Step 704 checks for an error. If an error has occurred, the application 502 terminates through step 730 discussed further below. If there is no error, control proceeds to step 706. The application 502 directs the ACM 204 to load into the system memory 104 and bind to the appropriate database management system module 516. Step 708 performs an error check. If an error has occurred in loading the database management system 516, control proceeds to step 724, described below. If no error has occurred, control is able to proceed to step 710 and all the required runtime loadable control modules (GUI 514 and DBMS 516) are in memory and operating. Step 710 calls the INIT 602 function. The INIT 602 function, discussed in further detail below, initializes the data and user interface components in preparation for display to the user. Step 712 checks for an error in the initialization. If an error has occurred, the application 502 exits at step 730. If there is no error, step 714 calls the DRAW 604 function to draw the entire screen. A loop is then entered at step 716. Step 716 calls the RUN 606 function of the ACM 204. This function will process all user input and react accordingly until an error occurs, or user input generates a command that the ACM 204 doesn't know how to process. At step 718 a check is made to see if the return code from the ACM 204 indicates if there is an unknown command, which indicates there is processing to be done by the application. If so, the application 502 processes its specific functions at step 720, then loops to step 716. If there is no unknown command, control proceeds to step 722. At step 722, if the return code from the ACM indicates that the user wishes to terminate the application or an error has occurred, the application proceeds to step 724. If there is no error, control goes to step 732 which loops back to step 716. At step 724, the application 502 calls the END 616 function, discussed in further detail below, to request the ACM 204 to close the application. At step 726, the application 502 requests that the ACM 204 unbind from the database modules. At step 728, the application 502 unbinds from the ACM 204. At step 730, the application is exited.

FIG. 8 illustrates the flow of the INIT 602 function. INIT 602 is an initialization function for the ACM 204. The initialization routine is responsible for setting up the screen, opening the database and initializing any data.

Control of the INIT 602 function begins at step 800. At step 802 global data pointers are initialized to the TEMPLATE.sub.-- RUNTIME, TEMPLATE.sub.-- SCREEN and TEMPLATE.sub.-- DATA structures of the ACM data structures 528 in the application 502. These data structures are described in Appendix C. Step 804 calls the command dispatcher 618 to initialize the screen. The screen is initialized by creating an application work window for the application 502, setting up the color palettes, and drawing the title line 414 and menubar 404. The TEMPLATE.sub.-- SCREEN structure (Appendix C) defines all the necessary elements. Step 806 adds any application defined components that are defined in the TEMPLATE.sub.-- SCREEN structure to the operating environment 504. Step 808 opens all the GUI and application defined components so that they are properly registered with the operating environment 504. The application 502 defines its components in the pCmps array in the TEMPLATE.sub.-- SCREEN structure. Step 810 checks to see if an error has occurred. If there is an error, control proceeds to step 812 to close the components that have been opened and delete the application defined components that have been added. Control then proceeds to step 824, described below. If there is no error at step 810, control proceeds to step 814. At step 814 the database file as indicated by the pFile element of the TEMPLATE.sub.-- DATA structure (Appendix C) is opened. This is done by calling functions in the data handler 624. The data handler 624 creates the appropriate DBMS structures and calls the database management module 516. Step 816 will initialize the international structure pintl that is in the TEMPLATE.sub.-- RUNTIME structure. The international structure is used by the application 502 to determine the defined country's currency symbol, date and time formats. Step 818 checks to see if an error has occurred. If there is an error, control goes to step 824. If there is not an error, control proceeds to step 820 and checks to see if there is data to be read from the database to initialize the components. If there is data to be read, the command dispatcher 618 is called at step 822 with an appropriate initialization command to read one or more records from the DBMS 516. Control then goes to step 824 where the base window is reactivated. Control returns to the application 502 with the current status in step 826.

The DRAW 604 function consists of a set of routines that define the screen handler 620. These routines are accessible by the ACM 204 so that the screen can be updated as needed, and are also accessible by the application 502. This module accepts an identifier (ID) as input that indicates which portions of the screen are to be drawn. These ID's can be one of the following with the associated action performed:

DRAW.sub.-- SCREEN--draws the entire screen including the menubar and title line.

DRAW.sub.-- WORK--draws the area below the menubar.

DRAW.sub.-- CMPS--draws all components

DRAW.sub.-- STATS--draws all static elements. These include static strings, pictures, and icons.

REDRAW.sub.-- CMPS--draws all components that have their redraw flag set, then resets the redraw flag.

DRAW.sub.-- MB--draws the menubar without setting the redraw flag. This must be called whenever a menuitem changes its state so that the new state will be reflected if the user selects that menubar. This includes graying, enabling, checking, and unchecking of menubar items.

DRAW.sub.-- ALL.sub.-- MB--sets the menubar redraw flag, then draws the menubar.

DRAW.sub.-- TITLE--draws the title line

ERASE.sub.-- MB--removes the current menubar.

FIG. 9 is a flow chart illustrating the general method of the RUN 606 function (tm.sub.-- run). This is the main control loop in the ACM 204 that runs components, processes component return codes, performs database commands, processes the menubar and interprets user events.

Control of the RUN 606 function begins at step 900. At step 902, a check is made to determine if the component with focus has changed. Focus refers to which component on the screen will receive the user's input. For example, in FIG. 4, focus is directed to the highlighted item 410 in the listbox 402. Focus may be indicated by particular colors for an editfield, by a dashed box surrounding a pushbutton, by an inverted title on a listbox, or some other graphic means. Focus change is detected by comparing prev.sub.-- focus and focus.sub.-- id elements of the TEMPLATE.sub.-- RUNTIME structure of the ACM data structures 528. (Appendix C). If focus has changed at step 902, then the command dispatcher 618 is called at step 904 to process the focus change. Focus change processing saves any modified data that needs to be saved, and initializes the new component receiving focus. Initialization of the new component includes such interface characteristics as selecting text in an editfield, setting the cursor position correctly or initializing an UNDO menu item. At step 906, a check is made to see if any error occurred at step 904. If an error has occurred, control goes to step 930 to return to the application 502. If no error occurs in step 904, control proceeds to step 908. At step 908 the colors of the component that lost focus are reset to their defaults. The previous component's redraw flag is set. The redraw flags are part of the TEMPLATE.sub.-- SCREEN structure (Appendix C).

Control then resumes at step 910. The command dispatcher 618 is instructed to redraw the components defined by the application 502. The command dispatcher 618 is subsequently described in detail later. Only those components whose redraw flag is set will be redrawn. All the redraw flags are then reset. At step 912, the colors are set for the component with focus. The setting of colors for a component with focus implements the CUA standard that the component with focus will be displayed on the screen with a different color set than all the other components. Step 911 allows the application 502 to specify that program execution of the RUN 606 module begins at step 912. The component with focus is run in step 914. When a component is run, a call is made to a function in the operating environment GUI 514. The user input is directed to the component. When the user performs an action that the component should report to its caller, control returns from the component. The return code of the component is placed in the return.sub.-- code element of the TEMPLATE.sub.-- RUNTIME structure (Appendix C).

Step 915 allows the application 502 to specify that program execution of the RUN 606 module begins at step 916. At step 916, a call to the action interpreter 610 is made to determine if there is an associated command that needs to be performed by the ACM 204. The action interpreter 610 will be explained further with reference to FIG. 10. As a result of processing in step 916, there may be user input to be evaluated. The user input is stored in the Event element of the TEMPLATE.sub.-- RUNTIME structure (Appendix C).

Step 917 allows the application 502 to specify that program execution of the RUN 606 module begins at step 918. The current command in the tmpl.sub.-- command element of the TEMPLATE.sub.-- RUNTIME structure (Appendix C) is passed to the command dispatcher 618 at step 918, then the control loop is entered at step 920. Step 919 allows the application 502 to specify that execution of the RUN 606 module begins at step 920. Step 920 checks if an error occurs as a result of processing that has been executed in step 916 or step 918. If an error has occurred, control goes to step 930.

The user originated event is evaluated at step 922 by a call to the event interpreter 612. The event interpreter 612 is described with reference to FIGS. 11A and 11B. Step 924 checks to see if any errors have occurred. If an error has occurred, control goes to step 930. If no error occurs at step 924, the focus must be checked at step 926 to see if it is going to change as a result of the previous calls to the action interpreter 610 and/or the event interpreter 612. If focus is changing, control goes to step 928, otherwise control goes to step 932 where it loops back to step 902. In step 928, the ACM 204 checks to see if the application 502 has indicated it is to be notified on a focus change and if so, control goes to step 930. At step 930, control is returned to the application 502. If the application is not to be notified on a focus change, control proceeds to step 932 where it loops back to step 902.

FIG. 10 illustrates the control of the action interpreter 610. The action interpreter 610 processes the return code from the component and determines if there is an event to be read, if there is a command to be executed and/or if control should return to the application 502.

Execution of the action interpreter function begins at step 1000, where the return code of the component is checked to determine if the component has been modified. If the component has been modified, control proceeds at step 1002 to set the modified flags in the TEMPLATE.sub.-- INFO structure (Appendix C). If the current component is an editfield the modified flag in the TMPL.sub.-- EDIT structure (Appendix C) is also set. Step 1004 determines if there is an event waiting to be read from the operating environment GUI 514. If there is no event waiting to be read, step 1006 determines if the component return code indicates that the application 502 should be notified. If the application 502 is to be notified, step 1008 sets the tmpl.sub.-- command and start.sub.-- state elements of the TEMPLATE.sub.-- RUNTIME structure appropriately based on the return code. This allows control of the RUN 606 module to begin at step 911, 915, 917, or 919 (FIG. 9) as needed when the application 502 subsequently calls the RUN 606 module. Control then goes from step 1008 to step 1024 to return the current status. If notification is not required from step 1006, control goes to step 1016 discussed below.

If a determination is made at step 1004 that an event is to be read, control proceeds to step 1010. The event is placed in the Event element of the TEMPLATE.sub.-- RUNTIME structure (Appendix C). At step 1012, the component type and event type are checked to determine if the event is to be ignored. An example of events ignored by the ACM 204 are unused arrows from a scrollbar component. If the event is to be ignored, step 1014 purges the event, and control continues with step 1016.

Step 1016 checks the current component structure to determine if there is a command associated with the component return code. Each component definition starts with a TMPL.sub.-- HEADER structure as described in Appendix C. Within this structure is a pointer to an array of TEMPLATE.sub.-- CMDS structures. Each structure can specify an ACM command to be executed when the associated return code is encountered for that component. An example of the use of a TEMPLATE.sub.-- CMDS structure is when a listbox indicates that when selection changes in the listbox, a new record should be read. That is accomplished in the TEMPLATE.sub.-- CMDS structure by setting the tmpl.sub.-- command element to CMD.sub.-- LIST.sub.-- NEW.sub.-- RECORD and setting the ret.sub.-- code element to CMP.sub.-- SELECT.sub.-- CHANGE. If a TEMPLATE.sub.-- CMDS structure is found that matches the component return code and the tmpl.sub.-- command is not NULL in step 1018, step 1020 will send the command to the command dispatcher 618 to be executed. If no match is found or the command is NULL, the current status is returned in step 1024.

Step 1022 will set the start.sub.-- state element of the TEMPLATE.sub.-- RUNTIME structure (Appendix C) based on the return status from the command dispatcher. The current status is returned in step 1024.

FIGS. 11A and 11B are flow charts illustrating the method of the procedural code implemented in the event interpreter 612. The method is previously referred to at step 922 in the discussion of FIG. 9. The event interpreter 612 function interprets the user oriented events or inputs and the current component state, to generate commands to be sent to the command dispatcher 618. An event is a stored user action. Commands associated with user events include exiting an application, halting execution, running a different task (ie., an accessory or task switch), and changing focus from component to component via the Tab, arrow keys of the keyboard 110, or the pointing device 112. Commands associated with user events also include a variety of pull down menubar commands such as Edit Cut, Edit Copy, Edit Paste, or the like. An ACM command is a collection of function calls to one or more handlers. ACM commands (see further discussion of the command dispatcher 618 below) may be directly associated with menubar items, thus eliminating the need for the application 502 to interpret user input of those menubar items. ACM commands may be used to identify GUI components such that when user input selects that component, the application doesn't have to translate that component identifier into an ACM command.

The method of the procedural code implemented in the event interpreter 612 begins at step 1100 when control passes to step 922 (FIG. 9). At step 1102, the Event element of the TEMPLATE.sub.-- RUNTIME structure is checked to determine the type of action being requested by the user. The TEMPLATE.sub.-- RUNTIME structure is described in Appendix C. At step 1104 a determination is made whether the event has been the selection of an external task. An external task is one that is performed wholly outside of the application 502. Examples of external tasks include an accessory program of the operating environment, a help module of the operating environment, or a task switch. If the event is an external task, then at step 1106, the current component must be checked to determine if control should return to the application 502 before performing the requested user action. At step 1108 if control is returning to the application, the start.sub.-- state in the TEMPLATE.sub.-- RUNTIME structure is set to indicate that the run module should be entered at step 917 (FIG. 9). The tmpl.sub.-- command element of the TEMPLATE.sub.-- RUNTIME structure is set to DO.sub.-- APPL.sub.-- COMMAND, the error code is set to the reason for return to the application 502, and control continues at step 1112. If the application 502 doesn't get notified at step 1106, step 1110 calls the command dispatcher 618 to execute the requested user action. The screen redraw flag will be set. At step 1112 the redraw flag for the screen is checked. If the screen redraw flag is set, at step 1114 the screen is redrawn. Control then continues at step 1128.

If the event is not an external task event at step 1104, control proceeds to step 1116. Step 1116 determines if the event is a command. If it is a command, the type of command is determined at step 1117 by the flow indicated in FIG. 11B, discussed below, then control goes to step 1128. In step 1118, if the event is a character, it is processed in step 1120 to determine if the event will cause a change of focus. Character events that can cause a change of focus are: TAB, SHIFT TAB, and arrow movement keys. If a change of focus occurs at step 1120, step 1122 sets the focus.sub.-- id element of the TEMPLATE.sub.-- RUNTIME structure to indicate the new focus. Control resumes from step 1122 and step 1120 at step 1128. At step 1124, if the event is a mouse event, the mouse event is purged in step 1126 and control goes to step 1128.

At step 1128, the Event structure in the TEMPLATE.sub.-- RUNTIME structure is set to NULL, to indicate that the event has been processed. At step 1130, the start.sub.-- state in the TEMPLATE.sub.-- RUNTIME structure (Appendix C) is checked to see if it is still set to indicate there is an event waiting to be processed. If this is so, the start.sub.-- state is set to START in step 1132, to indicate that all necessary processing has been accomplished and processing should continue looping in the main RUN loop. At step 1134, the error code that has previously been set is returned to the application 502 which is step 922 (FIG. 9).

FIG. 11B is a continuation of the flowchart of FIG. 11A illustrating the detail of interpreting the user input if that input is a command. At step 1136 control determines if the command is the Navigator command, a special menubar command. The navigator component is a special component at the bottom of the screen that aids the user in moving between applications. If the command is the Navigator command, control proceeds at step 1138 to set the command to the identifier of the navigator component. If at step 1136, the command is not the navigator command, control proceeds to step 1140. At step 1140, if the command is an ID of one of the components (indicated by being in a specific range of values), step 1142 sets focus.sub.-- id in the TEMPLATE.sub.-- RUNTIME structure to the new component. After setting the focus to the new component, control goes to step 1150 for return to step 1128 (FIG. 11A). At step 1144, the current component is checked to determine if control should return to the application 502 before performing the requested user action. At step 1146 if control is returning to the application 502, the start.sub.-- state in the TEMPLATE.sub.-- RUNTIME structure is set to indicate that the RUN 608 module should be entered at step 917 (FIG. 9). If control is not returning to the application 502, then step 1148 sends the requested user input to the command dispatcher 618 to be executed. At step 1150 control returns to step 1128 in FIG. 11A.

The command dispatcher 618 is a jump table of all commands supported by the ACM 204. Each command is a collection of function calls to one or more handlers (data handler 624, screen handler 620 and component handler 622) and to data conversion functions. The data conversion functions include a set of data transfer functions and a component reactions function described subsequently in detail. The command dispatcher 618 is accessed as needed by the ACM 204. It can also be accessed directly by the application 502 via the COMMAND 606 function shown in FIG. 6. Below is a partial listing of a jump table which may be used for the command dispatcher 618.

For example, the command for reading a new record when selection in a listbox changes, then displaying it on the screen (CMD.sub.-- LIST.sub.-- NEW.sub.-- RECORD) will jump to a block of code with the following set of functions:

READ DATABASE RECORD (new selection)--This function calls the data handler 624 and requests a new record be retrieved from the database, based on the criteria set in a TEMPLATE.sub.-- RECORD structure. The TEMPLATE.sub.-- RECORD data structure is nested within a TEMPLATE.sub.-- INFO structure within the TEMPLATE.sub.-- DATA structure (Appendix C).

DATA TRANSFER (number of fields, pDBASE buffers, pCMP buffers)--This is a set of functions one of which is to copy field information from the database data structures 526 (db.sub.-- get, db.sub.-- query Appendix A) into the individual GUI structures (EDITFIELD, LISTBOX Appendix B) for each component.

COMPONENT REACTIONS (new record)--This function sets information in each GUI component structure affected by the new data read in. For example this will push the correct radiobutton, convert julian dates to displayable dates, and set any redraw flags necessary. The component reactions function is described below with reference to FIG. 12.

REDRAW COMPONENTS()--This function calls the screen handler 618 to draw all components on the screen that have their redraw flag set.

The above READ DATABASE RECORD function involves making a call to the operating environment DBMS API 510. This function would be provided by a database management system. The above REDRAW COMPONENTS function is a call into the GUI API 508 of the operating environment. This function would be provided by any GUI system. These functions therefore will not be described further.

The DATA TRANSFER and COMPONENT REACTIONS functions are unique to the invention and allow the system 500 to generalize procedural code across many applications for reacting to user input or events as a specific application defines.

The data transfer functions of the command dispatcher 618 handle the updating of component data structures based on data read from the data handler 624 into database buffers. The database buffers are not shown but are described in the database data structures 326 of Appendix A. The data transfer functions also handle the converse of updating database data structures 524 based on the contents of the component data structures 526. The data transfer routines use the pBuf pointers (data buffer pointers) in the TEMPLATE.sub.-- RECORD structure, nested within the TEMPLATE.sub.-- DATA structure, and the db.sub.-- get structure of the TEMPLATE.sub.-- INFO structure, nested within the TEMPLATE.sub.-- DATA structure to determine what data is copied is which location. In the TEMPLATE.sub.-- RECORD structure an array of buffer pointers is provided that must correspond one to one with the array of components in the TEMPLATE.sub.-- SCREEN structure. The database returns a record into a single buffer in the db.sub.-- get structure. Each field in this buffer is delineated by a NULL character. The data in the db.sub.-- get buffer is parsed and copied into the array of buffer pointers from the TEMPLATE.sub.-- RECORD structure. The record number from the db.sub.-- get structure is placed in the TEMPLATE.sub.-- RECORD.rec.sub.-- num element.

FIG. 12 illustrates the operation of the component reactions function of the command dispatcher 618. The component reactions function is used to set the states of components and data, based upon the explicit commands being dispatched in the command dispatcher 618. The TMPL.sub.-- HEADER structure (Appendix C) which defines a component to the ACM 204 contains four fields for reaction codes. Each field can specify a reaction code for the component that can be sent to the component handler 622. The reaction fields are as follows:

AddReaction field : the component reaction for when the function "add a new record" has been selected.

NewReaction field : the component reaction for when a new record is read from the database file.

BeforeUpdate field : the component reaction indicating how data in the component should be converted before adding or updating a record in the database file.

AfterUpdate field : the component reaction indicating how data that was converted for use in the database should be converted back into a display format.

These reactions are performed automatically when certain user events occur that cause database access. However, it is understood that automatic performance of these functions is not limited to events occurring that cause database access.

The component reactions function illustrated in FIG. 12 begins at step 1200 where it is passed an identifier (ID) indicating which reaction field in the TMPL.sub.-- HEADER should be used to identify the component's reaction. At step 1202, the ID passed to the component reaction module is used to identify the appropriate field in the TEMPLATE.sub.-- HEADER for the reaction of the first component. If that field is null at step 1204, control goes to step 1208, discussed below. If a reaction exists for that field, control proceeds to step 1206 and sends the defined reaction and the current component pointer to the component handler 622 module to be executed. For example, a date component may contain the JULIAN.sub.-- TO.sub.-- STD4 reaction in the NewReaction field of its TEMPLATE.sub.-- HEADER. This will convert a julian formatted date (the format in which dates are stored in the database) into a format of mm/dd/yyyy and set the redraw flag of the component containing this date. If there are additional components to be processed at step 1208, control loops back to step 1202 to evaluate the next component. If there are no more components, this module exits back to the command dispatcher 618 at step 1210.

Additional examples of how a component might define its reactions are set forth below.

An editfield that is to display a date in the form mm/dd/yyyy, would contain the following reactions in each of the four fields in the TEMPLATE.sub.-- HEADER:

AddReaction=CURRENT.sub.-- DATE4--This will place the current system date in the editfield whenever the menubar command to add a new record is selected by the user.

NewReaction=JULIAN.sub.-- TO.sub.-- STD4--This will convert the data read from the database into the correct format for user display

BeforeUpdate=STD.sub.-- TO.sub.-- JULIAN--This will convert the data in the editfield into a julian date, so it will be in the correct format for the database.

AfterUpdate=JULIAN.sub.-- TO.sub.-- STD4--This will convert the data from julian format back into the suitable display format.

Another reaction that is commonly used for buttons is:

EVALUATE.sub.-- BUFFER--The data in an associated buffer is used to set the state of a TMPL.sub.-- BUTTON component (usually this is the NewReaction of a TMPL.sub.-- BUTTON). The atoi (convert ascii to integer) function is performed on the contents of the components buffer. Based on the component type and the result of the conversion, the following occurs.

TMPL.sub.-- RB--radio button selected=result.

TMPL.sub.-- IB--icon button .bState=SELECTED if result |=0

.bState=DESELECTED if result==0

TMPL.sub.-- PB--push button .bState=PB.sub.-- DOWN if result |=0

bState=PB.sub.-- UP if result==0

TMPL.sub.-- CB--check box .bState=CB.sub.-- CHECKED if result|=0

.bState=CB.sub.-- UNCHECKED if result==0

The foregoing examples are given to further explain the method of component reactions and are not intended to be limiting.

The print function 614 provides a general report generation tool that the application 502 may use to format printed output of record oriented reports. The print function 614 initializes the printer 108. The print routines will automatically fill in a form defined by the application 502 with data read from the disk storage 114. Data is read by making calls to the data handler 624. Data is transferred from the database data structures 526 into the ACM print buffers. The ACM print buffers are part of the ACM data structures 528. The data in the print buffers is converted into a printable format by making calls to the data conversion code 512.

FIG. 13 illustrates the flow of control of the END 616 function of the ACM 204.

The END 616 function begins at step 1300. At step 1302 control proceeds by setting up global data pointers to the application TEMPLATE.sub.-- RUNTIME, TEMPLATE.sub.-- SCREEN and TEMPLATE.sub.-- DATA structures (Appendix C). Step 1304 closes the database file as indicated in the TEMPLATE.sub.-- DATA structure (Appendix C). This is done by calling functions in the data handler 624. The data handler 624 creates the appropriate DBMS structures and calls the database management module 516. Step 1306 closes all the GUI components listed in the TEMPLATE.sub.-- SCREEN structure. Step 1308 removes any added application defined components that are listed in the TEMPLATE.sub.-- SCREEN structure from the operating environment. Step 1310 closes the application work window and resets the color palettes of the operating environment. Step 1312 unbinds from the ACM. At that time, the ACM unbinds from the operating environment GUI module 514. Reference is made to the DeskMate Development System manual for a further explanation of unbinding a module prior to program termination. Step 1314 returns to the application 502.

While the invention has been described with specific references to a single preferred embodiment and certain alternatives, there is no intent to limit the invention to that particular embodiment for those specific alternatives. For example, one could implement the application management system in another operating environment for the development and operation of a number of applications. The CUA interface defined by this system may differ according to preferred standards. Input devices are not limited to a keyboard or pointing device and may contemplate any means by which data may be retrieved, such as telecommunication services or other electronic devices. The true scope of the invention is defined not by the foregoing description, but by the following claims. ##SPC1##