SEQUENTIAL INFORMATION INTEGRATION SERVICE FOR INTEGRATING TRANSFER OF FILES OR OTHER DATA ENTITIES BETWEEN A PLURALITY OF PROGRAM MODULES AND A STORAGE IN A COMPUTER

Abstract: A number of program modules (32, 34, 36) are sequentially controlled by a procedural user interface (PUI) (38) and an operating system (40) to perform tasks. Transfer of files or other data entities between the modules (32, 34, 36) and a storage (13) is seamlessly integrated by a sequential information integration service (SIIS) (50). For reading a file from the storage (13), the PUI (38) or the operating system (40) generates a read command including a filename designation which can include a pathname, complete filename or wildcard characters. The read command can also include one or more arguments such as a user or group access code and an error message to display if the required file is not found. In an automatic mode, the service (50) automatically selects the most recent file corresponding to the filename designation and arguments, or displays the error message if a file meeting these criteria is not found. In a manual mode, the read command includes a manual selection argument which controls the service (50) to display a list of files (64) corresponding to the filename designation and arguments in a dialog box or window (60) for manual selection. The read command can further include a prompt message (62) for display in the window (60) together with the list of files (64).

Description: SEQUENTIAL INFORMATION INTEGRATION SERVICE FOR INTEGRATING TRANSFER OF FILES OR OTHER DATA ENTITIES BETWEEN A PLURALITY OF PROGRAM MODULES AND A STORAGE IN A COMPUTER BACKGROUND OF THE INVENTION Field of the Invention The present invention generally relates to the art of computers, and more specifically to a sequential infor a- tion integration service for integrating transfer of files and other data entities between a plurality of program modules and a storage in a computer. Description of the Related Art Software developers have conventionally designed programs for commercial and personal use which perform a single function such as word processing. Integrated software packages are also available which include, for example, a word processor, a data base and a spreadsheet. However, it is often desired to perform functions which are not found in a single software package, such as creating and editing a document, and faxing the document to a remote location. The conventional method for performing this task is to use a word processor to create and edit the document, and the save the document as a file on a hard disk or other storage media. A fax program is then called to read the stored file from the hard disk and fax it to the desired location. The prior art method is complicated, and requires substantial technical expertise on the part of the user. This is inefficient, and is especially undesirable in the majority of business applications in which the users are not computer experts and cannot spare time from their primary jobs for in-depth computer training. Another problem involved in sequentially using several different programs is transferring the proper data files between the different applications. For example, a user might utilize a word processor to create, edit and save several different documents with different filenames at different times. At a later time, the user might have to fax one of the files to another location. In order to accomplish this, the user has to search the storage to locate the proper file, and select it for transmission by the fax program. This is disadvantageous in that the user must have technical knowledge of the directory structure of an operating system, and also in that a large number of files of different types might be stored by a number of users in a particular directory. Locating the desired file can be unacceptably time consuming. Although in some applications a file name can be •'hard-coded" and unambiguously identifiable, this is impractical in an application such as word processing since only one data file can be saved with a particular filename. An emerging trend in program development is to design generic program modules which can be integrated in various combinations to perform a specific task. A procedural user interface (PUI) is a shell which integrates and controls the operation of a number of such program modules. The PUI interacts with the operating system (UNIX, MS- DOS, etc.) and a windows program to display the tasks or functions which can be performed by the program modules in windows or dialog boxes as text or icon options. This greatly simplifies the operation of the system, and minimizes the amount of technical knowledge required of the user. An example of a window program suitable for use with a PUI is the Neuron Data Open Interface ® , which is avail¬ able from Neuron Data USA of Palo Alto, CA as described in a sales brochure dated May, 1991. An example of a word processing program module, printer control program module and fax program module which are integrally controlled by a PUI is illustrated in FIG. 1. A general purpose computer 10 includes a processing unit 12 with a mass storage media 13 such as a hard disk, a display screen 1 , a keyboard 16 and a mouse 18. A number of "buttons" are displayed in a dialog box or window on the screen 14, including a "CREATE" button 20, an "EDIT" button 22, a "PRINT" button 24 and a "FAX" button 26. The tasks represented by the buttons 20, 22, 24 and 26 are activated or "launched" by positioning a pointer 28 over the selected button 20, 22, 24 or 26 using the mouse 18, and clicking a button on the mouse 18 to enter the selection. Although not illustrated in detail, selecting the CREATE button 20 will typically cause the word processing program to run, preceded by a message prompting the user to enter a filename for a new file to be created. Selecting the EDIT button 22 will also typically cause the word processing program to run, preceded by a message prompting the user to enter the filename of a file to be edited. Especially if the file to be edited was not created recently, the user may have forgotten the filename. In this case, the user will enter a null filename, question mark or the like and the word processing program will control the operating system to display the directory structure of the storage 13, enabling the user to locate the desired file and select it for editing. A large number of files having similar names may have been stored in the storage 13 by different users, and considerable time, effort, trial and error may be required to locate the desired file. After a file is created and/or edited, the word processing program module enables the user to save the file to the storage 13 and exit to the PUI shell as illustrated in FIG. 1. The PRINT button 24 enables the user to print out a desired file and thereby produce a hard copy. The FAX button 26 enables the user to fax a desired file to a specified location. However, the PRINT and FAX functions are similar to the EDIT function in that the user must either know the filename of the desired file in advance, or search the directory structure to locate it. SUMMARY OF THE INVENTION In accordance with a method of the present invention, a number of program modules are sequentially controlled by a procedural user interface shell and an operating system to perform tasks. Transfer of files and other data entities including blocks of object code (objects) and database entities between the modules and the storage is seamlessly integrat- ed by a sequential information integration service (SIIS) . For reading a file from the storage, for example, a module generates a read command including a filename designation which can include a pathname, complete filename or wildcard characters. The read command can also include one or more arguments such as a user or group access code and an error message to display if the required file is not found. In an automatic mode, the service automatically selects the most recent file corresponding to the filename designation and arguments, or displays the error message if a file meeting these criteria is not found. In a manual mode, the read command includes a manual selection argument which controls the service to display all files corresponding to the filename designation and arguments in a window or dialog box for manual selection. The read command can further include a prompt message for display in the dialog box together with the files. The sequential information integration service is embodied as a software program written in source code, such as in the "C" programming language, and complied into object code for execution. The program consists of modules in the form of routines and subroutines which perform the required functions, including a command parser, an automat¬ ic file selector, a display controller and a manual file selector. The present sequential information integration service seamlessly integrates the program modules with little or no attention from the user. In a case in which a file to be read must be manually selected, only the appropriate files are displayed, rather than an entire directory structure as in the prior art, greatly reducing the time and training required for a user to operate the system. These and other features and advantages of the present invention will be apparent to those skilled in the art from the following detailed description, taken together with the accompanying drawings, in which like reference numerals refer to like parts. DESCRIPTION OF THE DRAWINGS FIG. 1 is a pictorial view of a general purpose computer programmed with a procedural user interface (PUI) for integrating a number of program modules; FIG. 2 is a block diagram illustrating the architec¬ ture of a sequential information integration service (SIIS) embodying the present invention in combination with an operating system and program modules in the computer of FIG. 1; FIGs. 3 and 4 are diagrams illustrating a manual file selection option of the SIIS; FIG. 5 is a block diagram illustrating the architec- ture of the SIIS; FIG. 6 is a flowchart illustrating the operation of a "MAIN" program routine of the SIIS; FIG. 7 is a flowchart illustrating the operation of a "GET FILE PRINT" routine; FIG. 8 is a flowchart illustrating the operation of a "GET FILE" subroutine; FIG. 9 is a flowchart illustrating the operation of a "PARSE ARGUMENTS" subroutine; FIG. 10 is a flowchart illustrating the operation of a "FIND RECENT FILE" subroutine; FIG. 11 is a flowchart illustrating the operation of a "PICK OPEN WINDOW" routine; FIG. 12 is a flowchart illustrating the operation of a "NOTIFY INSERT" routine; and FIG. 13 is a flowchart illustrating the operation of a "SELECT FILE" routine. DETAILED DESCRIPTION OF THE INVENTION The present invention provides a sequential informa- tion integration service for integrating transfer of data entities between a plurality of program modules and a storage in a computer. Although a preferred embodiment of the invention is described and illustrated in which the data entities are files which are transferred between program modules and a non-volatile mass storage media, the invention is not so limited, and any other applicable types of data entities, such as blocks of object code (objects) in memory, database entities, etc. can be advantageously transferred using the present system. An exemplary software system 30 for implementing the functions described with reference to FIG. 1 in accordance with the improvement of the present invention is illustrat¬ ed in FIG. 2. The system 30 includes a word processor program module 32, a printer program module 34 and a fax program module 36. A procedural user interface (PUI) 38 interacts with an operating system 40 such as UNIX and a windows program 42 such as Neuron Data Open Interface ® for integrating the operation of the modules 32, 34 and 36. A sequential information integration service (SIIS) 50 embodying the present invention interacts with the PUI 38, operating system 40 and windows program 42 for seamlessly integrating transfer of files (data entities) between the modules 32, 34 and 36 and the storage 13. The PUI 38 includes macros or scripts which are activated when the buttons 20, 22, 24 and 26 are selected by the mouse 18 and pointer 28. The SIIS 50 can be called from one of PUI scripts, or by the operating system 40. The script activated by the "CREATE" button 20 controls the word processor module 32 to run, preceded by a message prompting the user to enter a filename (specifier) for the new file to be created. The scripts activated by the buttons 24 and 26 cause the printer module 34 and the fax module 36 to run respectively. The scripts activated by the buttons 22, 24 and 26 cause a dialog box or window 52 to be displayed as illus¬ trated in FIG. 3. The window 52 includes a prompt message 54 such as "SELECT FILE", a "YES" button 56 and a "NO" button 58. The buttons 56 and 58 enable the user to select the automatic or manual mode of operation of the SIIS 50 respectively using the mouse 18 and pointer 28. For reading a file from the storage 13, the PUI 38 or the operating system 40 generates a read command including a filename designation (data entity designation) which can include a pathname, complete filename or wildcard charac- ters. The read command can also include one or more arguments (data entity arguments) such as a user or group access code and an error message to display if the required file is not found. In the automatic mode as selected by the NO button 58, the SIIS 50 automatically selects the most recent file in the storage 13 corresponding to the filename designation and arguments, or displays an error message if a file meeting these criteria is not found. In the manual mode as selected by the YES button 56, a manual selection argument is added to the read command which controls the SIIS 50 to display the filenames (specifiers) of all files corresponding to the filename designation and arguments in a dialog box or window 60 as illustrated in FIG. 4. The window 60 includes a prompt message 62 such as "PLEASE SELECT" and a list 64 of the files which meet the criteria. The user is then able to select the desired file from the list 64 using the mouse 18 and pointer 28. After selection of the desired file in the automatic mode or the manual mode, the PUI 38 causes the selected program module 32, 34 or 36 to load the selected file and run. An exemplary syntax for the read command is %GETFILE [-n (or -d) pathname/regular_expression] [-u] [-g] [-e "error string"] [-m "prompt message"]. %GETFILE is the program name of the SIIS 50 as called from the PUI 38. H is a file argument designating automatic mode operation. ■^ is a file argument designating manual mode operation. Pathname indicates the subdirectory in which the desired file is to be found. Regular expression is a filename designation which can include a complete filename with or without an extension, a partial filename and wildcard characters, or just wildcard characters. - \ e is a file argument indicating that a user error message is being supplied. "Error string" is the user supplied error message, ^m is a file argument indicating that a user prompt message 62 is being supplied. "Prompt message" is the user supplied prompt message 62. ^u is a user authorization access code file argument which is assigned to each user and indicates the file areas or types of files in the storage 13 to which the user is to be allowed access. ^g is similar to -u, but is a group authorization code file argument which indicates the working group to which the user is assigned. The user and group access codes are stored in the PUI 38 or the operating system 40, and are normally used to prevent users from having access to sensitive information for which they have no legitimate use. The access codes can alternatively be used for convenience in making visible only the user's own files in the storage 13. The SIIS 50 is preferably written in the "C" program¬ ming language and complied for use, although the invention is not limited to any particular programming language or structure. As illustrated in FIG. 5, the SIIS 50 includes a MAIN program routine 70 which is called by the PUI 38 or the operating system 40 using the read command. The MAIN routine 70 calls a GET FILE PRINT routine 72 which in turn calls a GET FILE subroutine 74. The GET FILE routine 74 calls a PARSE ARGUMENTS subroutine 76, a FIND RECENT FILE subroutine 78 and a PICK OPEN WINDOW routine 80. The PICK OPEN WINDOW routine 80 calls a NOTIFY INSERT routine 82 which in turn calls a SELECT FILE routine 84 which returns to the GET FILE subroutine 74. Although not illustrated or described in detail, the SIIS 50 also includes an appropriate error handling routine and appro¬ priate housekeeping functions. As illustrated in FIG. 6, the MAIN routine sets up interface parameters for the PUI 38, and calls the GET FILE PRINT subroutine 72. The GET FILE PRINT routine 72, as illustrated in FIG. 7, calls the GET FILE subroutine 74 to get the filename of the desired file, and returns the filename to the PUI 38 or to the operating system 40. In the UNIX operating system, the filename is printed to the standard output. The GET FILE subroutine 74 is illustrated in FIG. 8. The first operation the GET FILE routine 74 performs is to call the PARSE ARGUMENTS subroutine 76 which is illustrated in FIG. 9. The PARSE ARGUMENTS subroutine 76 separates the read command into its constituent parts. If the -d file argument is discovered in the read command, a dialog flag is set to logical TRUE to indicate that the manual mode of operation has been selected. If the -n file argument is not discovered in the read command, it indicates that the caller did not specify a particular filename designation. The pathname is set to a default value, preferably the current directory, and the filename is set to a wildcard. If the -n file argument is discovered in the read command, the pathname and filename are parsed. If the -e file argument is not discovered in the read command, the error message is set to a default value. It the -e file argument is discovered, the user supplied error message "error string" is parsed. The subroutine PARSE ARGUMENTS then looks for the -m file argument in the read command. If it is not discov¬ ered, the prompt message is set to a default value. It the file argument -m is discovered in the read command, the prompt message "message string" is parsed. If the -u file argument is discovered in the read command, the user access code is retrieved from the PUI 38 or the operating system 40 and used as a filter for the subsequent file selection operation. If the -g file argument is discovered in the read command, the group access code is similarly retrieved from the PUI 38 or the operating system 40. After the PARSE ARGUMENTS subroutine 76 has completed parsing the read command and returns to the GET FILE subroutine 74, the FIND RECENT FILE subroutine 78 is called as illustrated in FIG. 10. The FIND RECENT FILE subroutine 78 examines each file in the storage 13 corresponding to the filename designation. If the -u or -g file argument was discovered in the read command, each file is checked to determine it is authorized for the specified user or group. The date and time the file was last modified is examined and compared with the most recent file which was previously discovered. If the FIND RECENT FILE subroutine 78 finds a most recent file in the storage 13 which meets the specified criteria, it returns the filename to the GET FILE subrou¬ tine 74. If no file matching the criteria was discovered, the FIND RECENT FILE subroutine 78 sets the filename to null and returns to the GET FILE subroutine 74. After program control is returned from the FIND RECENT FILE subroutine 78 to the GET FILE subroutine 74, the filename which was returned is examined. If the filename is the null string, indicating that the desired file was not discovered, the GET FILE subroutine 74 returns to the GET FILE PRINT routine 72 with an appropriate error message. If only one file was discovered which matches the specified criteria, indicating that the caller designated the complete filename in the read command, the GET FILE subroutine 74 returns to the GET FILE PRINT routine 72 with the filename. This action will be performed even if the -d file argument was discovered in the read command, since selection of a file from a list which only includes itself is redundant. If the -d file argument was not present in the read command and the dialog flag is logically FALSE, indicating automatic operation, the GET FILE subroutine 74 returns to the GET FILE PRINT subroutine 72 with the filename. If the dialog flag is logically TRUE, indicating the manual selection operation, the GET FILE subroutine 74 calls the PICK OPEN WINDOW routine 80. The PICK OPEN WINDOW routine 80 is illustrated in FIG. 11, and controls the windows program 42 to open the dialog box or window 60 and then calls the NOTIFY INSERT routine 82. The NOTIFY INSERT routine 82 is illustrated in FIG. 12, and monitors the windows program 42 to capture control of the window 60. The NOTIFY INSERT routine 82 then calls the SELECT FILE routine 84. As illustrated in FIG. 13, the SELECT FILE routine 84 displays the prompt message 62 (user supplied or default) and a list of all files which correspond to the filename designation and file arguments in the read command in the window 60, and examines the files in the list in a manner similar to the FIND RECENT FILE subroutine 78 to discover and highlight the most recent file and then return to the GET FILE subroutine 74. The GET FILE subroutine 74 waits for the user to select a file from the list 64 using the mouse 18 and pointer 28. Upon selection, the GET FILE subroutine 74 returns to the GET FILE PRINT subroutine 72 which in turn returns to the caller with the selected filename. While an illustrative embodiment of the invention has been shown and described, numerous variations and alternate embodiments will occur to those skilled in the art, without departing from the spirit and scope of the invention. For example, the window 52 and associated operations described with reference to FIG. 3 can be omitted, and the control flow can proceed directly from the main menu of FIG. 1 to the file list 64 display of FIG. 4. The files or other data entities can be represented by specifiers other than filenames, such as shape types for objects corresponding to graphic images in volatile memory. Accordingly, it is intended that the present invention not be limited solely to the specifically described illustrative embodiment. Various modifications are contemplated and can be made without departing from the spirit and scope of the invention as defined by the appended claims. These modifications include, but are not limited to, the sequential integration of database query results through structured query language (SQL) commands as well as sequential integration of objects such as text, graphic images, and sounds which are "cut and pasted" through clipboards as embodied in the Apple Macintosh Operating System ® .

Claims: WE CLAIM: 1. In a computer system including a computer (10), a storage (13) and a control system (38,40), a sequential information integration service (50) for integrating data entity transfer between a plurality of program modules (32,34,36) and the storage (13), characterized by compris¬ ing: a command parser (76) for parsing a read command from the control system (38,40) specifying a data entity to be read from the storage (13) into one of the modules (32,34,36), said read command including at least one of a data entity designation and a data entity argument; and an automatic data entity selector (78) for automatically selecting a most recent data entity in the storage (13) corresponding to any data entity designation and any data entity argument in said read command as parsed by the command parser (76) for reading into said module (32,34,36) . 2. A service (50) as in claim 1, in which: said read command further includes a manual selection argument; and the service further includes: a display controller (80,82) for disabling the automatic data entity selector (78) and displaying all specifiers in the storage (13) corresponding to any data entity designation and any data entity argument in said read command as parsed by the command parser (76) in response to said manual selection argument; and a manual data entity selector (84) for enabling manual selection of one of said displayed speci¬ fiers for reading the data entity having said selected specifier from the storage (13) into said module (32,34,- 36) . 3. A service (50) as in claim 2, in which: data entities are stored in the storage (13) in accordance with access codes; said read command includes a data entity argument that specifies one of said access codes; and the display controller (80,82) displays only specifiers of data entities which are stored in the storage (13) in accordance with said specified access code. 4. A service (50) as in claim 2, in which: said read command further includes a prompt message; and the display controller (80,82) displays said prompt message together with said specifiers. 5. A service (50) as in claim 2, in which: said read command can further include a prompt message; the display controller (80,82) displays said prompt message together with said specifiers if said read command includes said prompt message; and the display controller (80,82) displays a default prompt message together with said specifiers if said read command does not include a prompt message. 6. A service (50) as in claim 1, in which: data entities are stored in the storage (13) in accordance with access codes; said data entity argument specifies one of said access codes; and the automatic data entity selector (78) selects said most recent data entity only from data entities which are stored in the storage (13) in accordance with said specified access code. 7. A service (50) as in claim 1, in which the automatic data entity selector (78) displays an error message if no data entities in the storage (13) correspond to any data entity designation and any data entity argument in said read command. 8. A service (50) as in claim 1, in which: said read command further includes an error message; and the automatic data entity selector (78) displays an error message if no data entities in the storage (13) correspond to any data entity designation and any data entity argument in said read command. 9. A service (50) as in claim 1, in which: said read command can further include an error message; the automatic data entity selector (78) displays said error message if said read command includes said error message and if no data entities in the storage (13) correspond to said data entity designation and said data entity argument; and the automatic data entity selector (78) displays a default error message if said read command does not include an error message and if no data entities in the storage (13) correspond to said data entity designation and said data entity argument. 10. A service (50) as in claim 1, in which: the control system (38,40) comprises: an operating system (40) which is capable of generating said read command; and a procedural user interface (38) which interacts with the operating system (40) for controlling the program modules and is also capable of generating said read command.

Inventors: BARRETT WILLARD H, NGUYEN HA T, BARRETT, WILLARD, H., NGUYEN, HA, T.
Applicants: HUGHES AIRCRAFT CO, HUGHES AIRCRAFT COMPANY
Application year: 1994
Main classification: G06F9
IPC codes: G06F3, G06F9, G06F12, G06F17