The gmAPI Paradigm
The paradigm for using a gmAPI executable with gmStudio is a bit different and is engaged by than using gmStudio with gmBasic. The difference begins with setting the TScript field on a gmProj Task. To use gmBasic, the TScript field specifies and gmPL translation script template. To use a gmAPI executable, the TScript field is set to the path of a .NET Exe rather than an xml gmAPI.exe file.
- gmPLgmBasic: gmStudio prepares an actual translation script (JobID.xml) for the task being processed by detokenizing %placeholders% and merging ScriptRules found in with the template translation script file specified by the Tscript field for each task in the gmProj file.
gmStudio then spawns gmBasic.exe as a separate process passing the actual translation script as a command line argument. gmBasic.exe executes the gmPL commands specified in the actual translation script. - gmAPI: gmStudio prepares a task information file (JobID.xml) .
gmStudio based on the attributes of the task being processed. gmStudio spawns your gmAPI Exe (e.g. Upgrade.exe) passing the task information file as a command line argument. Upgrade.exe uses the TaskInfo, ScriptRules , and gmslLibrary APIs as needed to invoke gmBasic services.
...
| Tip |
|---|
The use of ScriptRules file(s) are optional in the gmPL approach because a developer may can insert custom XML commands (i.e. Select, Registry, Fix, Refactor) into the template translation script manually. However, since there are no translation scripts with the gmAPI approach, ScriptRules are typically required to integrate XML. |
...
| Warning |
|---|
gmAPI is built on Managed-Native integration. The implementation of gmBasic services that power gmAPI services were developed to work in the gmBasic.exe console application and some behavior may be non-intuitive. We are working on improvements to this API to make it more a natural fit for custom managed EXEs. |
See also
gmAPI reference and samples are here: gmAPIIntroduction
...