System and method for automatically creating source code example files for an application program in a plurality of programming languages

[0003] 1. Field of the Invention

[0004] The present invention relates to a system and method for automatically generating source code example files for an application program, wherein source code example files are automatically generated for a plurality of different programming languages and/or a plurality of different operating systems.

[0005] 2. Description of the Related Art

[0006] Many application programs are distributed with examples which illustrate or exemplify operation of the application program. In many instances, the application program includes examples in a number of different programming languages. For example, NI-DAQ, the device driver and Windows driver library set for National Instruments Data Acquisition (DAQ) devices, is generally distributed with code examples in Microsoft Visual C++, Microsoft Visual Basic, and Borland C++.

[0007] In the NI-DAQ application program, the code examples generally had the following characteristics. First, each example included extensive Windows graphical user interface (GUI) code, so that the user could easily change key data acquisition parameters while running the example program. Second, each example accommodates a wide variety of DAQ devices. However, not all devices were supported by all NI-DAQ functions. Therefore, each example implemented run-time branching to make device specific function calls. Thirdly, each example was written individually for each language and three different Windows operating system (OS) versions (3.1x, 95, and NT), each taking advantage of the programming language specific features through language and OS specific project files. Finally, each example was delivered in the form of source code and ready-to-run executables.

[0008] While each delivered example illustrated an important aspect of using the NI-DAQ dynamic link library (DLL) through the exported application programming interface (API) calls, they had the following shortcomings with respect to the above mentioned characteristics. First, it was very difficult to find the few NI-DAQ function calls located in the few hundred lines of GUI code. In one example, there were 340 lines of code, which only included 2 lines of NI-DAQ function calls. Thus the NI-DAQ programming example resembled a Windows programming tutorial. Secondly, when the NI-DAQ driver set was upgraded to include support for new data acquisition (DAQ) devices, a programmer had to maintain the different versions of the examples for each programming language and OS. Thirdly, when a new version of the programming language was released (e.g.: Microsoft Visual C++ 5.0), the project files were required to be upgraded due to compatibility issues. Also, each example used slightly different sequences of function calls, which required that support personnel know the subtle differences between the examples. Fourthly, the size of the executables and/or run-time engines (e.g. the Visual Basic 3.0 run-time DLL is over 700 kB) required to run the executables required increased amounts of disk space for the installation media (1.44 MB floppies). Fifthly, the examples included no information on how physical signals were to be connected to the data acquisition devices while being used with these examples.

[0009] Finally, customers typically requested “code snippets”, which are concisely written source code files showing how to perform a certain task. The customer support engineers were thus required to spend time writing these short examples for customers.

[0010] Due to the above shortcomings and the large amount of required maintenance for the example source code, application developers were reluctant to provide a large number of examples to the users. The NI-DAQ library is a versatile driver library which supports over 50 different DAQ devices and signal conditioning units, as well as a wide variety of tasks for each DAQ device. Although the NI-DAQ User Manual did explain in flow charts how to use the set of NI-DAQ functions to perform various basic data acquisition tasks, the nature of the API calls required detailed expertise when it came to programming. Without examples, customers had a very difficult time programming with the NI-DAQ function calls.

[0011] Therefore, an improved system and method is desired for easily generating example programs for an application program, preferably in a plurality of different programming languages and/or for a plurality of different operating systems.

[0012] The present invention comprises a system and method for generating example source code files for an application program in a computer system. In the preferred embodiment, the system and method is used for creating source code example files for the NI-DAQ driver software from National Instruments.

[0013] The developer first generates a code flow description file. The code flow description file is written in a code flow description language which is independent of a plurality of programming languages, i.e., which includes only common programming elements from the plurality of programming languages. The developer then specifies one or more target programming languages. The present invention includes a Code Generator which generates one or more target example source code files in the specified target programming languages in response to the code flow description file. The Code Generator operates to parse the code flow description file to produce a code flow description data structure, and then generate the one or more target example source code files in the specified target programing languages in response to the code flow description data structure.

[0014] In one embodiment, the system further includes a program editor for creating the code flow description files. The system further comprises a function database which stores functions of the application program written in the code flow description language. The function database is useable in creating the code flow description file.

[0015] Thus, one object of the present invention is to easily create a large collection of examples that illustrate only a single basic data acquisition task, and reduce GUI code to a bare minimum.

[0016] Another object of the present invention is to have all of the examples of the same basic data acquisition task call the same sequence of NI-DAQ functions, so that an end user can examine an example in one language (e.g. Visual C++), and expect the same exact functionality from a counterpart example written in another programming language (e.g. Visual Basic).

[0017] Another object of the present invention is to simplify the programming style of example programs to accommodate a wide range of programming expertise levels among end users.

[0018] Another object of the present invention is to create source code program files which provide sufficient and consistent documentation elements in the example source code itself regarding what the example does, what functions it uses, its key parameters, and what signal connections to the DAQ device are necessary. It is also an object to allow comments in the source code to explain any special tips and techniques in that part of the source code.

[0019] Another object of the present invention is to reduce the storage space required by the installation media by providing only the files necessary to compile the source code into executable programs, but not the executables themselves.

[0020] Another object of the present invention is to maintain the example code flow in a single database file for ease of maintenance, so that the single database file could then be used to generate other types of files, such as on-line help documentation, file lists, etc.

[0021] A better understanding of the present invention can be obtained when the following detailed description of the preferred embodiment is considered in conjunction with the following drawings, in which:

[0022] FIG. 1 illustrates a computer system utilizing the present invention;

[0023] FIG. 2 illustrates the operation of the code generator of the present invention;

[0024] FIG. 3 illustrates various software components comprised in the preferred embodiment of the present invention;

[0025] FIG. 4 is a screen shot illustrating use of the generator according to the present invention;

[0026] FIG. 5 illustrates operation of the end user selecting target source code example files for installation created using the present invention;

[0027] FIG. 6 is a flowchart diagram illustrating operation of the present invention;

[0028] FIG. 7 is a state machine illustrating operation of the parsing method utilized by the code generator; and

[0029] FIG. 8 illustrates an online help file created using the present invention.

[0030] Referring now to FIG. 1, an illustrative computer system 100 which is programmed according to the present invention and which operates according to the present invention is shown. The computer system 100 preferably comprises a video display screen 102, a keyboard 104, and a mouse 106 as shown. The computer system 100 also includes various standard components, including at least one central processing unit (CPU), a memory, a hard drive, one or more buses, and a power supply. The computer system 100 preferably includes a memory media, such as an installation media, e.g., floppy disk(s) or a CD-ROM, a system memory and/or a non-volatile memory, e.g., a hard drive, on which computer programs according to the present invention are stored. In the preferred embodiment, the present invention comprises a software program stored on the memory and/or hard drive of the computer 100 and executed by the CPU. The CPU executing code and data from the memory thus comprises a means for executing the steps described below. The computer system 100 may thus be used to create source code example programs or files according to the present invention, as described below.

[0031] FIG. 2—Software Components

[0032] FIG. 2 illustrates the software components comprising the system and method of the present invention. As shown, the user creates a code flow description file 202 in a code flow description language. The code flow description file 202 specifies the example to be created in a pre-defined format, i.e., the code flow description language. The code flow description language is preferably a generic to a plurality of different programming languages and/or operating systems. Stated another way, the code flow description language incorporates the core or common programming constructs from each of the a plurality of different programming languages. The syntax of the code flow description language is discussed in greater detail below.

[0033] Once the user creates the code flow description file 202, the code flow description file is provided to a Code Generator 204. The Code Generator 204 analyzes the code flow description file 202 and is operable to create one or more source code examples in selected programming languages and/or for selected operating systems. In FIG. 2, the examples shown comprise the Code Generator 204 generating C source code example programs for Visual Basic, LabWindows CVI, Microsoft Visual C++, Borland C++, and an RTF file.

[0034] As discussed further below, in the preferred embodiment the Code Generator 204 operates to parse the code flow description file to create a code flow data structure. The Code Generator 204 then operates to convert the code flow data structure into each of the different examples for the different programming languages. This conversion utilizes the specific syntax rules required for each of the specific programming languages.

[0035] In the preferred embodiment the code flow description file includes a plurality of code flow segments or records. The Code Generator 204 operates to parse the code flow segments in the code flow description file to create corresponding code flow data structures for each segment. The Code Generator 204 then operates to convert the code flow data structures into each of the different examples for the different target programming languages.

[0036] FIG. 3—Software Components of the Preferred Embodiment

[0037] FIG. 3 illustrates a preferred embodiment of the invention. In FIG. 3, the system and method of the present invention further includes a program flow editor 212 which is useable for creating code flow description files 202 utilizing the code flow description language.

[0038] The system and method preferably also includes a function database 214 which stores code flow segments for functions currently available in the application program for which examples are being created. The function database 214 comprises a database of functions written in the code flow description language which are used by the program flow editor in creating code flow description files. Since it is presumed that these functions will be repetitively used in each of the code flow description files being created, the database 214 is provided to help the user to insert these functions, pre-written in the code flow description language, directly into a code flow description file being generated. This simplifies development of the code flow description files. Also, if the application program function changes in the future, it is only necessary to replace the function database 214. This allows additional reuse of existing code flow description files. In one embodiment, the program editor includes search and replacement tools for search and replacement of certain function calls, and thus existing code flow description files are not rendered obsolete when the function database 214 changes.

[0039] The function database 214 receives information from a Documentation Database 218 which describes other current information relative to the application program. The Documentation Database 218 contains a list of functions exported by the application program. The Documentation Database 218 comprises function names, parameters, types, parameter lists, whether or not a certain function is exported or not exported, whether or not it is documented, etc. This information is referenced by the Function Database 214 and is also used by the program flow editor 212 in creating code flow description files.

[0040] Where the application program for which examples are being created is the NI-DAQ driver application from National Instruments, the system and method preferably includes an NI-DAQ function database 214 which stores code flow segments for NI-DAQ functions available in the current release of the NI-DAQ driver software. The NI-DAQ function database 214 receives information from a document database 218 which describes other current information relative to the NI-DAQ software. The program flow editor 202 is operable to use the code flow segments in the function database to form program code flow segments within the code flow description file. The Documentation Database 218 contains a list of functions that NI-DAQ exports.

[0041] The code flow editor 202 further uses tools and prototypes 216 to aid in creating code flow description files. The program flow editor tools and prototypes 216 comprises a list of code flow definition segments or files written for functions that each example program may call, but which are not necessarily part of the function database 214. For instance, the set of examples contains a set of function calls such as NI-DAQErrorHandler and NI-DAQDelay, which have their own prototypes. However, these functions are not known as NI-DAQ API functions and thus are not included in the function database 214. Thus the tools and prototypes 216 allows the user to incorporate external functions, i.e., functions external to the application program, e.g., non-NI-DAQ functions, into the code flow description file.

[0042] As shown, the program flow editor 212 is used to create a code flow description file 202. The code flow description file is then provided to the Code Generator 204 for creation of the various example programs and/or documentation.

[0043] The present invention thus comprises a Code Generator 204 which analyzes a code flow description file and is operable to generate various example programs in selected programming languages and/or for selected operating systems. The present invention further includes a novel code flow description language for creating code flow description files. The present invention further includes a program flow editor which is used to aid in creating code flow description files. The present invention thus provides a suite of example creation or generation tools which are operable to easily create example programs and documentation. The system and method of the present invention are operable to create a large collection of source code examples simply and efficiently.

[0044] In the preferred embodiment, where the application program is the NI-DAQ driver level software, the present invention allows the creation of a large collection of examples that illustrate a single basic data acquisition task and which also reduces GUI code to a minimum.

[0045] The present invention also operates to make all examples of the same basic data acquisition task call the same sequence of functions, such as NI-DAQ functions. Thus, an end user can examine the example in one language, e.g., Visual C++ and expect the same exact functionality from a counterpart example written in another programming language, e.g., Visual Basic. Thus, the present invention provides consistency in examples over a plurality of different programming languages.

[0046] The present invention further simplifies the programming style in which the example programs are written to accommodate a wide range of programming expertise levels among end users.

[0047] The present invention fisher provides sufficient and consistent documentation elements in the example source code itself regarding what the example does and the functions that the example uses, as well as its key parameters. For the NI-DAQ application program, the present invention also provides documentation on what signal connections to the DAQ device are necessary. Also, the present invention inserts comments in the source code to explain any special tips and techniques in their respective sections of the source code.

[0048] The present invention further reduces the storage space required by the installation media, since the present invention enables the developer to provide only the files necessary to compile the source code into executable programs, and thus does not require the executables themselves.

[0049] The system and method of the present invention is also operable to maintain the example code flow description files in a single database file for ease of use and maintenance. Further, this database of example code flow description files can also be used to generate other types of files such as online help documentation, file lists, etc.

[0050] FIG. 4—Screen Shot of the Examples Factory Code Generator

[0051] FIG. 4 is a screen shot of the Examples Factory Code Generator of the preferred embodiment. The Examples Factory Code Generator reads in a code flow description (CFD) file and generates different types of target files. As shown, when the Code Generator is executed, the following options are specified:

[0052] one Code Flow Definitions File

[0053] one target directory—base directory where the generated files will be stored

[0054] one target language—target programming language for generated files

[0055] one operating system—target operating system for generated files

[0056] type of target—source files, file listing, or examples spreadsheet file

[0057] After the above selections have been specified, the user clicks on the Do It! button to start generating the target files.

[0058] Code Flow Segments

[0059] The code flow definition file includes a collection of code flow segments. A sample code flow segment appears as follows. (The syntax is explained in more detail later).

[0060] If the user of the Examples Factory Code Generator selects a C language (e.g. LabWindows/CVI, Microsoft Visual C++, Borland C++) for any operating system, the code flow definition listed above is translated as follows. Here note the common elements between the example below and the code flow definition above.

[0061] As illustrated in the example above, since the source code compiles into a “console” application, there are no complicated calls to set text in a graphical user display, instead a simple, well understood printf call is used.

[0062] It is noted that, in the case of Visual Basic, where there is a user interface by default, the Code Generator maps the above print statement to print out to a predefined text box on a Visual Basic form, and behaves very much like the printf statement in C.

[0063] The types of “Source” targets that can be generated in the present embodiment are as follows:

[0064] Microsoft Visual C++ source code and MAKE file; (for Windows 3.1: ver 1.5; for Win32 OSes: ver 2.0 and above)

[0065] Microsoft Visual Basic source code and project file; (for Windows 3.1: ver 3.0; for Win32 OSes: ver 4.0)

[0066] Borland C++ source code and batch file (to help build the application) (for version 5.0x)

[0067] National Instruments LabWindows/CVI (for version 3.0.1 or later)

[0068] Microsoft Word Rich-Text Format (RTF) files that are to be compiled into on-line help documentation

[0069] As shown in FIG. 4, for the “File listing” target type, preferably only the Filename and Descr fields are extracted and placed into a single file. This filelist file is used as a catalog that lists out brief descriptions of all the examples. Thus the end-user of the examples is not required to look through each directory and open each example source code to determine what the example does.

[0070] For the “Export to Notes DB” (spreadsheet) target, the Filename, the NI-DAQ functions used, the Category, the Keywords, and the target operating system are extracted and placed into a single tab delimited, spreadsheet format file. This spreadsheet file is preferably used by the developer of the examples to match up examples with DAQ devices, and is not intended for use by the end user.

[0071] FIG. 5—Packaging of the Examples for Distribution with an Application Program

[0072] The products of the Examples Factory Code Generator 204 are preferably copied into a predetermined location network drive location where most application software files are maintained (a.k.a. source tree). The files are then gathered by a separate installer creation process, so that the examples can be distributed as part of the NI-DAQ distribution media (CD-ROM).

[0073] When the end-user receives the installation media to install the application program, e.g., NI-DAQ, and selects “Third Party Compiler Support” from the installer option menu, as shown in FIG. 5, these examples, as well as supporting DLLs and files are installed in to the directory of the end-user's choice. (The installer is based on a separate install product.)

[0074] Code Flow Definition Language Syntax and Composition Rules

[0075] According to the present invention, the developer first generates code flow description files written in a code flow description language. The present invention includes the Code Generator 204, which is operable to generate the different target files based on the code flow description file, written in the code flow description language, and programming language specific rules. To ensure that all code flow description elements can be mapped to features in each programming language, the code flow description language preferably only uses or incorporates a bare minimum of the feature set, e.g., the commonality of the feature set, of supported programming languages, such as:

[0076] only one code module per program, and one routine per code module

[0077] variables declared locally inside the routine and always assigned initial values at the beginning of the routine

[0078] very simple control flow elements, such as if-elseif-endif, while-end, do-while

[0079] very little support for simple arithmetic—increment and decrement only (basic arithmetic operations being considered in future version of the Code Flow Description specification)

[0080] ability to include any standard function call to other code modules (e.g.: Dynamic Link Libraries), as long as the project files are responsible for resolving externally defined functions

[0081] some utility features, such as Comment and Print.

[0082] Also, to simplify operations for the writer of the code flow description file, the code flow parser preferably includes the following features.

[0083] leading white spaces and trailing white spaces are “eaten” (ignored)

[0084] a semi-colon (;) at the beginning of a line to embed comments that will not get extracted to the target files,

[0085] an at-symbol (@) at the end of a line to allow for multiple lines to be considered as one long line (so the code flow description can be formatted nicely into less than 80 characters per line, which is a feature that programmers like)

[0086] code flow description files can (theoretically) be up to 2{circumflex over ( )}31 lines in length

[0087] The common elements to each code flow description are the following:

[0088] a code flow opener, denoted by BeginCodeFlow

[0089] a Filename, denoted by Filename:

[0090] a Description, denoted by Descr:

[0091] a list of keywords that describe the functionality of the example, denoted by TaskIDList:

[0092] a category in which the example belongs, denoted by Category:

[0093] signal connection information to assist the end user of the example in figuring out how to connect physical signals to the data acquisition device to make the program work, denoted by PinConnInfo:

[0094] a code block opener, denoted by an open curly bracket ({)

[0095] variable declarations, denoted by Var:

[0096] function calls and control flow elements, which are denoted by Func: and have their own opener and closer curly brackets)

[0097] a code block closer, denoted by a close curly bracket (})

[0098] a code flow closer, denoted by EndCodeFlow

[0099] The variable declaration syntax is as follows:

[0100] Var: <Type>, <Name>, <InitialValue>, <KeyParamT/F>, [ArraySize]

[0101] The <Type> field specifies the type of variable (i8, u8, i16, u16, i32, u32, STRING).

[0102] The <Name> field specifies the name of the variable.

[0103] The <InitialValue> field specifies the initial value of the variable.

[0104] The <KeyParamT/F> field specifies whether this variable is a “key parameter” in this program or not. That is, if the value of this variable is changed, then the behavior of the program would change drastically. A “True” or “False” is specified.

[0105] The optional field <ArraySize> indicates whether the variable name denoted by <Name> is an array or not. In the case where the variable is an array, the <InitialValue> field can be a common initial value for all array elements, or the individual initial values can be specified by a |-delimited list of values. (e.g.: 1|2|3|4).

[0106] The function declaration syntax for ordinary functions is as such:

[0107] The <funcName> field specifies the function name. If <funcName> is Comment, INCR, or DECR, only the first Param: is accepted and the rest will be rejected.

[0108] The <retVarName> field specifies the variable to which the function will assign its return value.

[0109] The Param: indicates that the following is a parameter, and is to be listed in order. The <paramName> field specifies a variable name or a constant to be passed into the function. The Param: can also have an optional asterisk (*), which indicates to the parser that this parameter is to be passed by address in C languages. (Ignored for Visual Basic, since every parameter is passed by address to begin with.)

[0110] For control-flow functions, the syntax is as such:

[0111] The <controlFlowFunc> field indicates the name of the control flow function, which could be if, elseif, endif, while, wend, do, or dowhile. Once a control flow function is specified, the Code Generator's internal state machine goes into a new state so that the balancing of such control flow blocks are ensured at parsing time. Also, if the <controlFlowFunc> is an endif, wend, or do, no Cond: statements are necessary.

[0112] The Cond: keyword indicates the following is a condition for if, elseif, while, and dowhile. The <CondVar> field indicates a variable name to check.

[0113] The <compareType> field can contain GT (greater than), GE (greater than or equal to), LT (less than), LE (less than or equal to), EQ (equal to), or NE (not equal).

[0114] The <compvalue> field contains either another variable or a constant to compare.

[0115] The <conj> field indicates whether the next condition statement is to be ANDed or ORed, or if this current condition is the LAST, in which case the next line is a close-curly bracket.

[0116] Below is a code flow description file that contains most of the elements of the code flow description language.

[0117] For all functions (Func:) that are not part of the code flow specification, the project files or MAKE files (that also get generated at the same time the source code files are) must resolve the externally declared functions. Most such functions are in a DLL for Windows, which can be resolved by linking in an import library.

[0118] FIG. 6—Flowchart of Operation of the Present Invention

[0119] FIG. 6 is a flowchart diagram which illustrates the use and operation of the present invention. As shown, in step 402 the user creates a code flow description file written in the code flow description language. In the preferred embodiment, the user utilizes the program flow editor 212 in creating the code flow description file. The syntax of the code flow description file was discussed above.

[0120] In step 404 the Code Generator 204 parses the code flow description file to produce a code flow description data structure, also referred to as a code flow record. The operation of this parsing step is discussed further below. Example source code for a code flow description data structure is included as Appendix 1.

[0121] In step 406 the Code Generator 204 verifies the code flow data structure, i.e., verifies that the code flow data structure created includes the requisite components. Thus, once the code flow description file has been parsed into the code flow record data structure, the Code Generator 204 determines if certain fields have been filled out. The code flow record data structure fields include file name, description, task ID list, category, pin connection information, at least one variable, and one function. The Code Generator 204 verifies that these fields include data. Also, for the task ID list and category, the Code Generator 204 ensures that these contain the valid key words.

[0122] In step 408 the Code Generator 204 generates one or more target source code example files in response to the code flow record data structure. In step 408 the Code Generator 204 utilizes the particular syntax rules which are particular to the respective target programming language in order to generate target source code with the correct syntax for that respective programming language. The source code of a function which maps a CodeFlowRecord data structure into a C source code file is included as Appendix 2.

[0123] Thus, once the code flow record data structure has been verified, then the Code Generator 204 generates the target source code example file(s) for each target programming language and/or operating system. The Code Generator 204 essentially operates to map the contents of the code flow record data structure into the appropriate programming language styles of the target programming languages.

[0124] In general, each programming language includes certain semantic rules in terms of creating a program. For instance, in Visual Basic, each variable has a data type indicator, either a percent sign for an integer or & for a long integer, and these are appended to the variable names as the program is constructed. In a similar manner, for each target programming language, the Code Generator 204 uses the syntax rules of the respective programming language in creating the target source code example file.

[0125] The Code Generator also follows certain rules for generating comments. For example, in Visual Basic a comment is always preceded by an apostrophe, whereas the C language utilizes a/* to begin a comment and an */ to end a comment. These types of semantic rules are enforced while the code flow record data structure is being mapped to a target source code file.

[0126] Also, while generating the source code file, the Code Generator 204 preferably creates a project file at the same time. A project file comprise a list of source code files which form the respective program. In the case of the C language, this occurs as a Make file, i.e., a regular Visual C++ Make file that is created with various inferenced rules for compiling a program and linking the executable. In the case of Visual Basic, the Visual Basic project file is created to include information such as the source files being included, etc.

[0127] In step 410 the Code Generator 204 generates any target documentation desired by the user utilizing the code flow record data structure. In the preferred embodiment, the Code Generator 204 generates the target documentation by concatenating the comments provided in the code flow description file into a textual documentation file.

[0128] The Code Generator has the following operational hierarchy (in psuedocode).

[0129] FUNCTION Go parse the whole Code Flow Description File

[0130] The “Open the Code Flow file identified by CodeFlowFileName” simply opens the file and returns a file handle.

[0131] The “Count the number of records in file” performs pre-processing to ensure that all “BeginCodeFlow” keywords have a matching “EndCodeFlow” keyword, and also counts the number of such pairs. (Each pair corresponds to a single code flow=an example program).

[0132] The “Get the next code flow record . . . ” is explained below.

[0133] The “Verify the code flow record data structure” performs a check to determine if the code flow record contains the required elements.

[0134] The “Generate the source using the CodeFlowRecord data structure” generates the target files from the CodeFlowRecord data structure, given the language, OS, and target directory. Fundamentally, this function calls language-specific functions to perform the actual work of mapping the CodeFlowRecord to different target formats. In other words, this function maps the CodeFlowRecord data structure to a source code file of the desired programming language.

[0135] The “Decide what to do next” determines if there are any more records, or if there was an error while generating the source. If any abnormalities happened, this will make the while-loop terminate with some error code. If there are no more records left, the while-loop terminates with an “EndOfFile” status code. Otherwise, the execution remains in the while-loop.

[0136] The “Get the next code flow record and store in a CodeFlowRecord structure” function is discussed below.

[0137] FUNCTION Get the next code flow record and store in a CodeFlowRecord structure

[0138] The “Get the next non-comment and non-blank line in code flow file” rejects any line that begins with a comment symbol (;) and also concatenates lines that end with the line-continuation symbol (@) with the next one.

[0139] FIG. 7 is a state diagram of the CodeFlowStateMachine. As shown in FIG. 7, the CodeFlowStateMachine is a state machine with 5 states. The BeginCodeFlow/EndCodeFlow transition marks the end of a single code flow record and allows the while loop to terminate. The central part of the Code Generator Parser State Machine reads the code flow description file into a data structure. The operation of the state machine can be readily understood with reference to the example code flow description file included above.

[0140] As shown, the state machine begins in an “Out of Code Flow” state. The state machine advances from the Out of Code Flow state to the “In Code Flow” state when a BeginCodeFlow command is detected in the code flow description file. If an “Else” statement is encountered in the Out of Code Flow state, the state machine advances to the “Error Condition (Exit)” state.

[0141] In the In Code Flow state, the Code Generator 204 extracts the Filename, Descr, TaskIDList, Category, and/or PinConnlnfo information into the data structure. If an EndCodeFlow command is detected, then operation returns to the Out of Code Flow state.

[0142] After the information is extracted in the In Code Flow state, when an open curly bracket “{” is detected, the state machine advances to the “In Program Block” state. If an EndCodeFlow command is detected in the code flow description file in the In Code Flow state, the state machine returns to the Out of Code Flow state.

[0143] In the In Program Block state, Variable (Var) and/or Function (Func) information, which does not require more information, is extracted into the data structure. If a Func requiring more information is encountered in the In Program Block state, the state machine advances to the “Waiting for Func Block Open” state. If an “Else” statement is encountered in the “In Program Block” state, the state machine advances to the “Error Condition (Exit)” state. If a close curly bracket “}” is encountered in the In Program Block state, the state machine returns to the In Code Flow state.

[0144] In the Waiting for Func Block Open state, if an open curly bracket “{” is detected, the state machine advances to the “in Func Block” state. If an “Else” statement is encountered in the Waiting for Func Block Open state, the state machine advances to the Error Condition (Exit) state.

[0145] In the In Func Block state, the Code Generator 204 extracts information inside the function block into the data structure, such as “Cond” commands for functions that require conditions and “Param” commands for functions that require parameters. If a close curly bracket “}” is encountered in the In Func Block state, the state machine returns to the In Program Block state. If an “Else” command is encountered in the “In Func Block” state, the state machine advances to the Error Condition (Exit) state.

[0146] After the parsing state machine executes to convert the code flow segments in the code flow description file into respective data structure(s), the data structure(s) are then extrapolated into the different target files with language specific rules, coding styles, and project files. Since the language syntax is part of the programming language itself, details regarding the exact syntax of each function call has been omitted for simplicity.

[0147] Generating the Example Programs from the Code Flow Data Structure

[0148] After the code flow description file has been parsed and the code flow record data structure has been created or filled, the Code Generator 204 performs the work of mapping each individual CodeFlowRecord data structure into the target files. As noted above, this operation comprises generating source code for a particular target programming language using the syntax rules of the particular target programming language. The source code of a function which maps a CodeFlowRecord data structure into a C source code file is included as Appendix 2.

[0149] As discussed above, in the current embodiment the target files are as follows:

[0150] Microsoft Visual C++

[0151] Borland C++

[0152] National Instruments LabWindows/CVI

[0153] Microsoft Visual Basic

[0154] On-line help RTF files

[0155] Filelist file

[0156] Spreadsheet (for internal use)

[0157] The C Languages

[0158] The C source code target files for the C-programming environments (VC++, BC++, CVI) are the same, since all environments accomodate a GUI-less program (commonly known as console applications). The variables definitions and function declarations are all placed inside the void main(void) routine. This was discussed above.

[0159] The project files for Visual C++ are makefiles, which provide the inference rules for compiling the source code and linking with the NI-DAQ import libraries. These make files use slightly different flags between 16-bit and 32-bit Windows.

[0160] The project files for LabWindows/CVI are PRJ files, which specify other file dependencies, and conform to the LW/CVI version 3.0.1 standards (also compatible with later versions).

[0161] The project files for Borland C++ are actually batch (.BAT) files, which help the end-user compile the source code and link the NI-DAQ import libraries for Borland C++. These batch files also provide some help on how to construct an Borland C++ .IDE file from its integrated development environment.

[0162] Visual Basic

[0163] For Visual Basic, to accommodate the PRINT statement as defined in the code flow description file, the generated Visual Basic form has a method called PrintText:

[0164] This function behaves like a printf statement in C on a command-based environment. The variables definitions and function declarations are all placed inside a command button method function called cmdDoOperation_Click() routine, as shown here:

[0165] The Visual Basic project files (.MAK for VB 3.0, .VBP for VB 4.0) simply contain a list of files that are part of the project.

[0166] On-line Help RTF files

[0167] As noted above, the present invention is useable for creating on-line help or documentation files. The RTF files for on-line help are preferably created using OLE Automation technology. In the Code Generator program, a Word.Basic object is instantiated, and formatting commands are invoked to specify the text that goes into the help file. Each code flow record is transformed to a single RTF file, which is then compiled into a Windows On-Line Help file using the Microsoft Help Workshop. FIG. 8 is a sample screen shot from the compiled help file. The text of this help file is consistent with the earlier AlonePoint.c source code example.

[0168] Supporting Files

[0169] In the preferred embodiment where the application program is NI-DAQ, several files are hand-created to supplement the generated example files. These hand-created files are as follows:

[0170] NIDAQEX.H—common header file for all C programming languages, containing function declarations and constant definitions

[0171] NIDAQEX.C—only for LabWindows/CVI, providing support for NI-DAQ Examples Utility functions (e.g. NIDAQErrorHandler)

[0172] NIDEX16.BAS and NIDEX32.BAS—only for Visual Basic, containing function declarations and constant definitions

[0173] NIDEX16.DLL/NIDEX16(B).LIB and NIDEX32.DLL/NIDEX32(B).LIB —a dynamic link library for the Nl-DAQ Examples Utility functions (used with VC++, BC++, and VB)

[0174] The project files link the above files in selectively for the target programming language.

[0175] Additional Features

[0176] In one embodiment, the code flow descriptor file itself can hold comments in multiple human languages. This allows the use of a single Code Flow Descriptor file which creates example programs with just the comments and the header descriptions translated to other languages (Japanese, French, German).

[0177] In the current embodiment, the code flow specification only supports one subroutine per code flow segment. In an alternate embodiment, the code flow description language supports examples with multiple subroutines or functions, such as examples that require other subroutines or functions that must be part of the example, for instance, callback functions.

[0178] In one embodiment, the Code Generator 204 includes a feature where the user of the Code Generator can specify a header template, and the code flow definitions file contains fields that match the given header template.

[0179] In one embodiment, calls to application program functions, e.g., NI-DAQ functions, are entered manually. Therefore, there is no guarantee that the products of the Code Generator 204 will compile and link properly until the source code is actually compiled and linked. In the preferred embodiment, the function prototype is provided from a separate function database, such as a Lotus Notes database, and cross-verified for syntax correctness.

[0180] In one embodiment, the Code Generator 204 includes a Command Line interface. As shown in the screen shot of FIG. 4, the Code Generator 204 itself has a GUI. In this embodiment, the Code Generator 202 can also be invoked with specific options from the Windows command prompt. Thus the example creation process can be made part of the daily automated builds of the application program.

[0181] Appendix 1 comprises example source code of a code flow record data structure created according to the present invention. The primary data structure is located at the end and is titled “tCodeFlowRecord”. This data structure contains the string fields for things such as filename, description, etc. and also arrays of other sub fields. The subfields are also data structures, and they are defined further up in the file.

[0182] Appendix 2 comprises source code of a function called “GenerateSourceC”, which operates to generate C source code from a code flow record data structure.

[0183] Although the system and method of the present invention has been described in connection with the preferred embodiment, it is not intended to be limited to the specific form set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the invention as defined by the appended claims.

[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]