The "function interface" directly maps BlitzMAX functions to a Lua counterpart. All functions of a given BlitzMAX module reside in a Lua table whose name is that of the underlying module: e.g., under Lua, the BlitzMAX function
createWindow found in module
BRL.MaxGUI is replicated by
brl being a global table). An optional "
import" mechanism makes all functions of a given module global, removing the need to prefix them with their module name.
MaxGuiExample contains two simple examples which illustrate the use of this interface.
Since Lua is a case-sensitive language (whereas BlitzMAX is not) the following naming conventions apply:
In case of any incertitudes just consider the function reference which is part of the package.
Parameter Handling and Type Conversion
The Lua function parameters equal those of the corresponding BlitzMAX function, any default values are properly respected (i.e., the corresponding Lua argument may be
nil). Types are converted as follows:
Noteworthy detail: since BlitzMAX has its own "garbage collection", any BlitzMAX object has to be explicitly referenced (from within BlitzMAX itself!) in order not to be removed shortly after its creation. This is done internally using BlitzMAX "handles" (which are one-to-one representatives of a given object) - in fact, its an object's handle which is passed to Lua rather than the object itself. As a consequence, it is now up to Lua to "destroy" any BlitzMAX object which is no longer required. Thus, every BlitzMAX "
createXXX" function (or "
loadXXX" or similar) which is used to create an object of type XXX now also has a "
destroyXXX" counterpart (within the same module) which must be called to remove that object.
Any BlitzMAX constants are also available within the table belonging to the defining module - their names have been kept in uppercase (e.g.
brl.event.EVENT_WINDOWCLOSE) as under BlitzMAX.