Method and apparatus for a dynamic application test facility5418941Abstract A dynamic application editor builds new application definition entries for and edits existing application definition entries without a need for a user to have an innate knowledge of the exact method required to invoke applications. Application definition entries describe an application's initiation, execution, procedural command language, macro syntax, and communication capabilities in an application independent manner. The dynamic application editor automatically locates, or accepts user specified existing application definition entries and presents them in a user friendly user interface for the user to edit. The user can view existing application definition entries, cut, copy and paste between application definition entries, edit and delete application definition entries, or browse entire sections of the active application definition file. Application definition entries may be entered into the dynamic application editor and tested with or without committing the entry permanently to the application definition file. If an application fails, the dynamic application editor can be used to invoke a trace environment to detect the reasons for failure of an application. Once the application definition entry is corrected, the dynamic application editor allows the permanent storage of the entry in an application definition file. Claims What I claim is: Description CROSS REFERENCE TO RELATED APPLICATION
TABLE A
__________________________________________________________________________
WPWIN=edname=WPWIN.EX edreal=WPWINFIL.exe ddesys=Wordperfect
ddetopic=COMMANDS macrofile=Macroplay(ovxenv)
macfile=Fileopen(FileName:"*FILENAME GOES HERE*") delim= *#
WINWORD=edname=WINWORD.EXE edreal=WINWORD.EXE ddesys=WINWORD
ddetopic=SYSTEM
macfile=[Fileopen .name="*filename goes here*"]
macrofile=[ToolsMacro .name="ovxsend", .show=1, .run] delim=
*#
AMIPRO=edname=AMIPRO.EXE edreal=AMIPROUI ddesys=AMIPRO
ddetopic=SYSTEM macrofile= macfile=[FileOpen("#filename
goes here#",1,"")] delim=*#
EXCEL=edname=EXCEL.EXE edreal=EXCEL ddesys=EXCEL ddetopic=
SYSTEM macrofile= delim*# macfile=[Open("*FILENAME GOES
HERE*)]
123W=edname=123w.exe edreal=MAIN123w.exe. ddesys=123W
ddetopic=Untitled macnofile= macfile=[RUN({ALT)fo(ALT "n"}
*FILE NAME HERE*{TAB 4}.sup..about.)] delim=*#
__________________________________________________________________________
The grammar shown in TABLE A starts with the name of the application. Taking the first application (e.g., WPWIN) in the application definition file, the entry consists of the edname (e.g., WPWIN.EXE) parameter which specifies the name of the program that is to be executed. The edname parameter is separated from other parameters for the application by the delimiter " ". The next parameter edreal (e.g., WPWINFIL.EXE) specifies the name of the program that ends up actually getting executed. The edname parameter, for some applications, is only a launching shell application for the real main executable program of an application. For example, WordPerfect for Windows which is manufactured by the WordPerfect Corporation, is initiated by WPWIN.EXE but its main executable file is WPWINFIL.EXE. Likewise Lotus 1-2-3 for Windows, manufactured by the Lotus Corporation, is initiated by 123W.EXE but its main executable file is MAIN123W.EXE. The ddesys parameter (e.g., WORDPERFECT) specifies the name of the DDE (Dynamic Data Exchange) server application. This parameter is followed by the ddetopic parameter (e.g., COMMANDS) which specifies the DDE topic of the DDE conversation. One skilled in the art will appreciate that DDE, and other protocols, support multiple conversations. The ddetopic indicates the specific conversation which this application is requesting. The macrofile parameter (e.g., Macroplay(ovxevn)) specifies the name of the application macro to be sent to the application program. The macrofile parameter is the name of an application macro to be executed by the application. The macfile parameter (e.g., FileOpen(FileName:"*FILENAME GOES HERE*") specifies the name of the application macro to be sent to the application with a DDEEXECUTE command in the case where the application is to be invoked with a parameter(s). The actual parameter is inserted in place of the text between the delimiters specified by the delim parameter 22. It will be appreciated by those skilled in the art that while the above-mentioned parameters are for a DOS/WINDOWS environment, the parameters are application dependent and not operating system dependent. It will also be appreciated that the grammar may be initially set up by a system administrator and made available for an end user. Finally, the delim parameter 22 (e.g., *#) specifies the delimiter token(s) which may be used to separate the actual parts of the application macro from part of the macro which is to be updated with the execution parameter string. Everything between the delimiters tokens is substituted for by the runtime parameter being passed to the application. This means the string inside the delimiters is substituted with the real information that is only available at runtime. For example, an editor may be called with a filename. The filename is maintained by a placeholder string until the actual data is known and the application is called. Turning now to the figures, and particularly FIG. 1, there is shown an entry panel 10 for the dynamic application editing facility editor. The application entries supported by the editor are displayed in the applications available listbox 11. Each of the listbox entries 11 corresponds to an application definition file (APPINT) entry 12. The APPINT entry 12 describes how to execute the application on a platform. The application name field 18 specifies the APPINT edname entry for the application which specifies the name of the program that is to be executed. The application executable field 25 specifies the APPINT edreal entry for the application which specifies the name of the program that ends up actually getting executed. The DDE application name 16 field specifies the APPINT ddesys entry for the application which specifies the name of the DDE server application. The DDE topic field 20 specifies the APPINT ddetopic entry for the application which specifies the DDE topic of the DDE conversation. The DDE macro command field 13 specifies the APPINT macrofile and macfile entries for the application which specifies the name of the application macro to be sent to the application without or with parameters, respectively. The actual parameters are inserted in place of the text between the delimiters in the macro file name delimiters field 22. The APPINT's delim entry 22 specifies the delimiters tokens which may be used to separate the actual parts of the application macro from that part of the macro which is to be updated with the execution parameter string. The delimiter field 22 can specify any number of delimiter characters but a delimiter token consists of one and only one character at any one time. The application INI identifier field 27 indicates the currently active APPINT entry identifier. This token is also the string which identifies the application to an application launcher. The current INI file field 14 specifies the path and filename of the file which is currently being updated by the editor program. The invention is also capable of supporting multiple files. A user can launch an application by manipulating the launch 24 button to immediately execute the application from the editor. One skilled in the art will appreciate that any of a number of well known editors may be modified to perform the indicated operations on the afore-mentioned parameters. One such editor is the WordPerfect editor manufactured by the WordPerfect Corporation. Turning now to FIG. 2, a flow diagram is shown for the major steps of the dynamic application test facility editor. The procedure starts at Block 30 where the necessary parameters are edited in an application definition entries file. At Block 32, the application is tested with the parameters entered at Block 30. The procedure then proceeds to Block 34 where the application is executed. At Block 36, the procedure saves and displays the execution information and exits at Block 38. With reference now to FIG. 3, at Block 40 the user selects a button on the application editing facility editor. A test is conducted at Block 42 to determine if the test button is selected. If NO, at Block 52 the button is processed accordingly. If YES, at Block 44 the procedure saves the current execution parameters for testing. At Block 46, the procedure checks to determine if tracing is requested. If YES, at Block 54 the procedure causes a setup of the trace environment. Else, at Block 48, the procedure executes the application according to the parameters entered. At Block 50, the procedure inspects the results. At Block 56 the procedure destroys the internal testing environment and exits at Block 58. Turning now to FIG. 4, at Block 60 the procedure parses and interprets the current parameters of the application definition file. The editor parses and interprets the parameters using the following steps: STEP 1: Break the parameters in the application definition file entry into each of the individual parameters (e.g., edname, edreal, etc. ). STEP 2: Store each of the individual parameters in internal tables, containing only the actual values necessary at execution. STEP 3: Search the operating system tables using the edreal name to determine if the target application is already executing. Start the application if it is not executing. STEP 4: Establish and open a conversation with the target application using the ddesys and ddetopic entries. STEP 5: Instruct the target application how application integration is to be accomplished using the macfile and nomacfile parameters. At Block 62, the procedure checks to see if the application is already executing. If NO, then at Block 72 the procedure executes the specified application. Else, at Block 64 the procedure sends commands to the application. The procedure then causes the application to be displayed as shown in Block 66. At Block 68 the procedure checks to see if the display was successful. If YES, the procedure exits at Block 70. Else, at Block 74, the procedure indicates a processing error and the procedure aborts at Block 76. With reference now on FIG. 5, a flow diagram is shown for setting up the trace environment. At Block 80, the procedure creates a trace window. The execution logic is then processed at Block 82. At Block 84, the procedure checks to see if the processing is completed. If NO, the procedure returns to Block 82. If YES, the procedure moves to Block 86 and checks to see if there is any trace activity. If YES, processing proceeds to Block 88 where the display trace is presented to the user. At Block 90, the procedure destroys the trace window and exits at Block 92 if no trace activity is detected. Turning now to FIG. 6, a data processing system 200 is shown where the operation of the present invention is carried out. The data processing system 200 consists of a processor 202 containing a CPU 204 and memory 206. Attached to the processor 202 is a scanner 220 for inputting information into the data processing system 200. In addition, a keyboard 216 is provided for entry of data by a user. Permanent storage is provided by hard disk storage 208 along with removable storage in the form of a floppy disk device 210. Program information or data may be inputted to the system by a floppy disk 212. A display device 218 is also provided to permit a user to view information and data processing within the data processing system. As can be seen, the dynamic test facility provides a quick and simple approach to test execution characteristics of one application calling another to another application. The user may immediately test out the dynamic integration of the programs by actually invoking the subject application according to the newly defined execution characteristics. Dynamic application testing is carried out by defining the execution characteristics for an application in an application definition entries file. This is easily done with the editor. The application definition file is dynamically modified in real time in a manner transparent to the user to simulate the actual conditions of application invocation. When application integration testing is completed, these conditions are automatically removed. The user can make the successful combination of application execution characteristics permanent entries in the application definition file. One skilled in the art will appreciate that surfacing the editor's user interface of the dynamic application test facility may be accomplished with a graphical button, pull-down menu, inclusion of a toolbar, etc. The user may test multiple applications interactions by simply invoking it. The user is therefore provided immediate, visual testing of applications integrated together. While the invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention.
|
Same subclass Same class Consider this |
||||||||||