System and method for automatically creating source code example files for an application program in a plurality of programming languages6237136Abstract A system and method for generating source code example 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. The user 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 user 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 programming languages in response to the code flow description data structure. The user can thus easily create a number of source code example files for a plurality of different programming languages and/or for a plurality of different operating systems. Claims I claim: Description BACKGROUND
;------------------------------------------------------------
; 1ch 1pt - immediate
BeginCodeFlow
Filename: AIlPt
Descr: Read one channel, one point at a time, immediately
TaskIDList: 1PT, 1CH, IMMED
Category: AI
PinConnInfo: Connect your analog signal to AI channel 1. @
The default analog input mode for the DAQ device will be used.
{
Var: I16, iStatus, 0, False
Var: I16, iRetVal, 0, False
Var: i16, iDevice, 1, False
Var: I16, iChan, 1, True
Var: I16, iGain, 1, False
Var: F64, dVoltage, 0.0, False
Var: I16, iIgnoreWarning, 0, False
Func: AI_VRead, iStatus
{
Param: iDevice
Param: iChan
Param: iGain
Param: dVoltage, *
}
Func: NIDAQErrorHandler,iRetVal
{
Param: iStatus
Param: "AI_VRead"
Param: iIgnoreWarning
}
Func: IF
{
Cond: iStatus, EQ, 0, LAST
}
Func: PRINT
{
Param: The voltage at AI channel, CONST
Param: iChan, 116
Param: is, CONST
Param: dVoltage, F64
Param: volts., CONST
}
Func: ENDIF
}
EndCodeFlow
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.
/************************************************************
*
* Example program:
* AI1Pt.c
*
* Description:
* Read one channel, one point at a time, immediately
*
* Example Category:
* AI
*
* Example Task Types:
* 1PT, 1CH, IMMED
*
* List of key parameters:
* iChan
*
* [Since variables are hardcoded, there is no guarantee that this
* program will work for your setup. This example is simply
* presented as a code snippet of how you can use NI-DAQ functions
* to perform a task.]
*
* List of NI-DAQ Functions used in this example:
* AI_VRead, NIDAQErrorHandler
*
* [NOTE: For further details on each NI-DAQ function, please refer
* to the NI-DAQ On-Line Help (NIDAQPC.HLP).]
*
* Pin Connection Information:
* Connect your analog signal to AI channel 1. The default analog
* input mode for the DAQ device will be used.
*
* [For further I/O connection details, please refer to your hardware
* User Manual.]
*
* [For further details on how to run this example, please refer to
* the NI-DAQ Examples On-Line Help (NIDAQEx.HLP).]
*
************************************************************/
/*
* Includes:
*/
#include "nidaqex.h"
/*
* Main:
*/
void main(void)
{
/*
* Local Variable Declarations:
*/
i16 iStatus = 0;
i16 iRetVal = 0;
i16 iDevice = 1;
i16 iChan = 1;
i16 iGain = 1;
f64 dVoltage = 0.0;
i16 iIgnoreWarning = 0;
iStatus = AI_VRead(iDevice, iChan, iGain, &dVoltage);
iRetVal = NIDAQErrorHandler(iStatus, "AI_VRead",
iIgnoreWarning);
if(iStatus == 0) {
printf(" The voltage at AI channel %d is %If volts..backslash.n",
iChan,
dVoltage),
}
}
/* End of program */
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. 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. The types of "Source" targets that can be generated in the present embodiment are as follows: Microsoft Visual C++ source code and MAKE file; (for Windows 3.1: ver 1.5; for Win32 OSes: ver 2.0 and above) Microsoft Visual Basic source code and project file; (for Windows 3.1: ver 3.0; for Win32 OSes: ver 4.0) Borland C++ source code and batch file (to help build the application) (for version 5.0x) National Instruments LabWindows/CVI (for version 3.0.1 or later) Microsoft Word Rich-Text Format (RTF) files that are to be compiled into on-line help documentation 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. 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. FIG. 5--Packaging of the Examples for Distribution with an Application Program 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). 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.) Code Flow Definition Language Syntax and Composition Rules 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: only one code module per program, and one routine per code module variables declared locally inside the routine and always assigned initial values at the beginning of the routine very simple control flow elements, such as if-elseif-endif, while-end, do-while very little support for simple arithmetic--increment and decrement only (basic arithmetic operations being considered in future version of the Code Flow Description specification) 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 some utility features, such as Comment and Print. Also, to simplify operations for the writer of the code flow description file, the code flow parser preferably includes the following features. leading white spaces and trailing white spaces are "eaten" (ignored) a semi-colon (;) at the beginning of a line to embed comments that will not get extracted to the target files, 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) code flow description files can (theoretically) be up to 2 31 lines in length The common elements to each code flow description are the following: a code flow opener, denoted by BeginCodeFlow a Filename, denoted by Filename: a Description, denoted by Descr: a list of keywords that describe the functionality of the example, denoted by TaskIDList: a category in which the example belongs, denoted by Category: 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: a code block opener, denoted by an open curly bracket ({) variable declarations, denoted by Var: function calls and control flow elements, which are denoted by Func: and have their own opener and closer curly brackets) a code block closer, denoted by a close curly bracket (}) a code flow closer, denoted by EndCodeFlow The variable declaration syntax is as follows: Var: <Type>, <Name>, <InitialValue>, <KeyParamT/F>, [ArraySize] The <Type> field specifies the type of variable (i8, u8, i16, u16, i32, u32, STRING). The <Name> field specifies the name of the variable. The <InitialValue> field specifies the initial value of the variable. 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. 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 .vertline.-delimited list of values. (e.g.: 1.vertline.2.vertline.3.vertline.4). The function declaration syntax for ordinary functions is as such:
Func: <funcName>,<retVarName>
{
Param: <paramName>[,*]
. . .
}
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. The <retVarName> field specifies the variable to which the function will assign its return value. 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.) For control-flow functions, the syntax is as such:
Func: <controlFlowFunc>
{
Cond: <CondVar>,<CompareType>,<CompValue>,<Conj>
. . .
}
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. The Cond: keyword indicates the following is a condition for if, elseif, while, and dowhile. The <CondVar> field indicates a variable name to check. 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). The <compvalue> field contains either another variable or a constant to compare. 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. Below is a code flow description file that contains most of the elements of the code flow description language.
;<-- this is a comment
BeginCodeFlow
Filename: DAQop
Descr: This is a test example that tests the @
code generator . . .
TaskIDList: BUF,1CH,BURST,IMMED,INTTRG
Category: AI
PinConnInfo: Connect analog signal to AICH1 @
default mode for device will be used.
; begin code <-- this is a comment
{
;STANDARD SYNTAX for local variable declarations . . .
; Var: iType, strName, strInitValue, flagKeyParam, [iArraySize]
; -if array, give first elem value.
; if empty, scalar
Var: I16, iStatus, 0, False
Var: i16, iDevice, 1, False
Var: i32, ITimeout, 200*18, True
Var: I16, iChan, 0, False
Var: I16, iGain, 1, False
Var: F64, dSampRate, 1000.0, True
Var: I32, 1Count, 1000, False
Var: i16, piBuffer, 0, false, 1000
Func: Comment
{
; the "@" at the end of a line is a line-continuation character
Param: This is a comment, blah blah blah . . . @
second line of comment . . . and no more!
}
; STANDARD SYNTAX for function declarations . . .
; Func: strName, strRetVar
; {
; Param: strName, * (optional: pass by address)
; for all params
; }
Func: Timeout_Config, iStatus
{
Param: iDevice
Param: 1Timeout
}
Func: DAQ_Op, iStatus
{
Param: iDevice
Param: iChan
Param: iGain
Param: piBuffer
Param: 1Count
Param: dSampRate
}
; must keep a list of functions other than IF, WHILE, DO, DOWEND
; for the following, treat "Cond" like "Param"
Func: IF
; open new block . . . keep open until next "elseif" or "endif"
{
; Cond: strCondVar, iCompareType, strCompValue, iConj
Cond: strCondVar1, GE, strCompValue1, AND
Cond: strCondVar2, GT, strCompValue2, OR
; don't use NAND, NOR - not supported!!!
;Cond: strCondVar3, LE, strCompValue3, NAND
;Cond: strCondVar4, LT, strCompValue4, NOR
Cond: strCondVar5, EQ, strCompValue5, XOR
Cond: strCondVar6, NE, strCompValue6, LAST
; iConj = LAST if last condition
}
Func: ELSEIF
; close previous block
; open new block . . . keep open until next "elseif" or "endif"
{
; Cond: strCondVar, iCompareType, strCompValue, iConj
Cond: elseifVar12, NE, elseifValue12, LAST
; iConj = LAST if last condition
}
Func: ELSE
Func: ENDIF
; close block
Func: WHILE
; open new block . . . keep open until next "wend"
{
; Cond: strCondVar, iCompareType, strCompValue, iConj
Cond: whileVar22, EQ, whileValue22, LAST
iConj = LAST if last condition
}
Func: WEND
; close block
Func: DO
; open new block . . . keep open until next "dowend"
; increment by one
Func: INCR
{
Param: 1Count
}
; print statement
Func: PRINT
{
Param: The current value of 1Count is, CONST
Param: 1Count, I32
}
; decrement by one
Func: DECR
{
Param: 1Count
}
Func: PRINT
{
Param: Now the value of 1Count is, CONST
Param: 1Count, I32
}
Func: PRINT
{
Param: The data of piBuffer at 1Count is, CONST
Param: piBuffer[1Count], I16
}
Func:DOWEND
; close block then check condition
{
; Cond: strCondVar, iCompareType, strCompValue, iConj
Cond: dowendVar32, GT, doWendValue32, LAST
; iConj = LAST if last condition
}
Func: Comment
{
Param: end of program
}
}
EndCodeFlow
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. FIG. 6--Flowchart of Operation of the Present Invention 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. 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. 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. 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. 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. 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. 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. 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. 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. The Code Generator has the following operational hierarchy (in psuedocode). FUNCTION Go parse the whole Code Flow Description File
(given CodeFlowFileName, TargetLang, TargetOS, TargetDir)
BEGIN
Open the Code Flow file identified by "CodeFlowFileName";
Count the number of records in file;
while there are more records and no errors exist
{
Get the next code flow record and store in a CodeFlowRecord data
structure (step 404);
Verify the code flow record data structure (step 406);
Generate the source using the CodeFlowRecord data structure
(step 408);
(given language, OS, target dir.)
Decide what to do next; (end of file, report error, continue)
}
END
The "Open the Code Flow file identified by CodeFlowFileName" simply opens the file and returns a file handle. 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). The "Get the next code flow record . . . " is explained below. The "Verify the code flow record data structure" performs a check to determine if the code flow record contains the required elements. 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. 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. The "Get the next code flow record and store in a CodeFlowRecord structure" function is discussed below. FUNCTION Get the next code flow record and store in a CodeFlowRecord structure
BEGIN
while there are more lines for the code flow record and no errors
exist
{
Get the next non-comment and non-blank line in code flow file;
CodeFlowStateMachine; (parse line of text and store into
CodeFlowRecord)
}
END
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. 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. 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. 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. 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. 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. 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. 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. 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. Generating the Example Programs from the Code Flow Data Structure 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. As discussed above, in the current embodiment the target files are as follows: Microsoft Visual C++ Borland C++ National Instruments LabWindows/CVI Microsoft Visual Basic On-line help RTF files Filelist file Spreadsheet (for internal use) The C Languages 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. 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. 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). 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. Visual Basic 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:
'
************************************************************
' SUBROUTINE: PrintText
' DESCRIPTION: PrintText to desired TextBox (upto 4096 characters)
' INPUTS: txtBox - TextBox to print on
' strText - Text to print
'
************************************************************
Sub PrintText(txtBox as TextBox, strText as string)
txtBox.Text = Right$(txtBox.Text + strText$ + Chr$(13) + Chr$(10),
LEN_PRINTTEXT)
txtBox.SelStart = Len(CStr(txtBox.Text))
DoEvents
End Sub
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:
'
************************************************************
' SUBROUTINE: cmdDoOperation_Click
' DESCRIPTION: The main NI-DAQ operations are here
'
************************************************************
Sub cmdDoOperation_Click( )
'
' Local Variable Declarations:
Dim iStatus As Integer
Dim iRetVal As Integer
Dim iDevice As Integer
Dim iChan As Integer
Dim iGain As Integer
Dim dVoltage As Double
Dim iIgnore Warning As Integer
iDevice% = 1
iChan% = 1
iGain% = 1
dVoltage# = 0.0
' Temporarily disable buttons for protection from `DoEvents`
cmdDoOperation.Enabled = False
cmdExit.Enabled = False
iStatus% = AI_VRead(iDevice%, iChan%, iGain%, dVoltage#)
. . .
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. On-line Help RTF files 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. Supporting Files 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: NIDAQEX.H--common header file for all C programming languages, containing function declarations and constant definitions NIDAQEX.C--only for LabWindows/CVI, providing support for NI-DAQ Examples Utility functions (e.g. NIDAQErrorHandler) NIDEX16.BAS and NIDEX32.BAS--only for Visual Basic, containing function declarations and constant definitions 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) The project files link the above files in selectively for the target programming language. Additional Features 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). 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. 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. 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. 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. APPENDIX 1 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. APPENDIX 2 Appendix 2 comprises source code of a function called "GenerateSourceC", which operates to generate C source code from a code flow record data structure. 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. ##SPC1## ##SPC2## ##SPC3## ##SPC4## ##SPC5## ##SPC6## ##SPC7## ##SPC8## ##SPC9##
|
Same subclass Same class Consider this |
||||||||||