5 Modules
Aubit4GL uses an abstraction layer for many of its functions. This means that the way Aubit4GL works can be controlled very tightly by the setting of various variables. These variables specify which library functions will be called from the compiler and/or 4GL program and hence affect the following areas:
|
Variable
|
Function
|
Library
|
|
A4GL_LEXTYPE
|
Set generation language
|
libLEX_???
|
|
A4GL_LEXDIALECT
|
Set language dialect (used for ESQL/C generation)
|
libESQL_???
|
|
A4GL_PDFTYPE
|
Specify the enhanced report handler
|
libEXREPORT_???
|
|
A4GL_HELPTYPE
|
Specify the help handler
|
libFORM_???
|
|
A4GL_MENUTYPE
|
Specify the extended menu handler
|
libMENU_???
|
|
A4GL_MSGTYPE
|
Specify the message handler
|
libMSG_???
|
|
A4GL_PACKER
|
’packer’ to use saving forms/reports etc (eg. XML)
|
libPACKER_???
|
|
A4GL_RPCTYPE
|
Specify the Remote Procedure Call handler
|
libRPC_???
|
|
A4GL_SQLTYPE
|
Specify the SQL handler
|
libSQL_???
|
|
A4GL_SQLDIALECT
|
Specify the SQL dialect to use
|
libSQLPARSE_???
|
|
A4GL_UI
|
output module to use to display the program
|
libUI_???
|
Aubit4GL’s libraries are created in the directory $AUBITDIR/plugins-1.2_14. With each new version of Aubit4GL a new plugins directory is created. This allows you to revert to earlier versions more easily.
Most of them have filenames of the form libXXX_YYY.so (except libaubit4gl.so) so for example :
libSQL_esql.so XXX=SQL YYY=esql
libUI_HL_TUI.so XXX=UI YYY=HL_TUI
The XXX represents the module type, the YYY the module name. Although Aubit4GL is distributed in a form which will be mostly Informix4GL compatible - you will almost certainly need to adjust some of these settings.
This is my list. Yours will probably be different! :
-
libaubit4gl.so libbarcode.so libchannel.so
-
libA4GL_:
file.so HTML.so string.so
These are miscellaneous extra libraries.
-
libDATA_:
menu_list.so module.so
report.so struct_form.so
These are internal libraries for reading data files.
-
libESQL_
INFORMIX.so POSTGRES.so
These are helper libraries used when A4GL_LEXTYPE=EC. The library used is taken from the A4GL_LEXDIALECT variable. This library is used to copy between native types and aubit types (eg for decimals, dates etc) . Not used when A4GL_LEXTYPE=C
-
libEXDTYPE_mpz.so
Example extended datatype library (implements the GNU mpz datatype).
-
libEXREPORT_:
NOPDF.so PDF.so
Extended report handling. libEXREPORT_PDF.so relies on having pdflib installed. It will not be generated otherwise. PDF reports are experimental.
-
libFORM_:
GENERIC.so NOFORM.so XDR.so
This is used to read, write, and process a form file. The library is specified by the A4GL_FORMTYPE variable. e.g.: A4GL_FORMTYPE=GENERIC If you have libFORM_XDR.so - that is probably the best one to use, so
$ export A4GL_FORMTYPE=XDR
If you don’t have libFORM_XDR.so, you’ll need to use the GENERIC packers
$ export A4GL_FORMTYPE=GENERIC
You will then also need to specify the GENERIC packer by setting A4GL_PACKER (see PACKER)...
-
libHELP_std.so
Always set to std - can be ignored
-
libLEX_C.so libLEX_CS.so libLEX_EC.so libLEX_PERL.so
Specifies the output format - currently only C and EC are supported. For C generation, calls are made to internal SQL functions within the library specified by A4GL_SQLTYPE (see SQL) For EC generation, a .ec file is generated which should be compiled used native database tools (like esql for informix and ecpg for postgres). If you can use EC generation - use it, performance will be better...
-
libLOGREP_:
CSV.so TXT.so
Logical report handling. Converts logical reports to different formats
-
libMENU_NOMENU.so
GUI Menu handling. Obsoleted (probably).
-
libMSG_NATIVE.so
Ignore
-
libPACKER_:
MEMPACKED.so PACKED.so
PERL.so XDR.so XML.so
This specifies the packer to use for reading and writing data files. The library is specified via the A4GL_PACKER variable. Use MEMPACKER for embedding forms into a program. Don’t use PERL unless you know what you are doing. PACKED, XML and XDR are all reasonable packers. The packer library is only used when FORMTYPE etc is set to GENERIC.
-
libRPC_NORPC.so libRPC_XDR.so
Specifies which RPC protocol to use - advanced stuff - still experimental.
-
libSQL_:
esql.so esql_s.so FILESCHEMA.so
ifxodbc.so nosql.so
mysql.so pg8.so pgodbc.so
sqlite3.so unixodbc.so
This is probably the most important setting, specified through SQLTYPE - this determines how Aubit is going to talk to the database. There are two distinct times that this is done: At compile time At runtime
-
libUI_:
CONSOLE.so lHL_TUIN.so HL_TUI.so
TUI.so TUI_s.so HL_GTK.so
This specifies how data will be displayed to the user. This handles all the UI controls (prompt,display, input etc)
CONSOLE - is a simple I/O module which does not use any control codes. Just printfs and fgets etc. Use this for programs to be called by cron, at, etc where they will run without a terminal (real or virtual) connected to stdout.
TUI - The traditional output for dumb terminals (real or emulated)
TUI-WIDE - for wide characters (e.g. UTF-8, Unicode, etc)
HL_TUI - Was to be the next version of TUI, abstracted to help make other HL_.. modules. There will no further development of this.
HL_TUIN - Ignore
HL_GTK - GTK version. This will not be developed further and will be superceded by the new generation of Visual Display Clients.
-
libXDRPACKER_:
menu_list.so module.so
report.so struct_form.so
This is a helper module when FORMTYPE etc are set to XDR. These contain the actual XDR routines.
The correct selection of these libraries is critical to the operation of Aubit4GL, because everything is so highly configurable.