4glWorks Online Manual - Introduction

Code organization
Code compilation tools
4gwdemo reference

Code organization

An appropriate directory structure and naming scheme for files, functions, tables and columns can ease a great deal the management of a project. This section illustrates convention used to organize 4glWorks code.

File naming scheme.

The name of files included in 4glWorks distribution adhere to the following format:
where a, an application qualifier, is

the application qualifier is only used in 4gl c and text files, since form and help files are only used in interactive apps.

mdl is a three letter code identifying the module, for instance

and t identifies the module type. for code it migth be something like

while forms use

optionally followed by another letter to distinguish otherwise equal file names. Text and help files have no type qualifier.


I've tried to stick to traditional Informix exts. except that there's no agreed upon convention for help source and cooked help files. I've used msg and hlp.
Application message files are plain text files and as such have a txt extension.
Any ext ending with h (except sh!) indicates an include file of some kind.

Directory structure

4glworks source has been divided into two directories, the first, named 4glworks, containing the application framework, the second, named 4gwapps/4gwdemo, containing a demo, minimal, working application. Each is organized as follows:

  • <dirname>/source
  • source code
  • <dirname>/c4gl
  • compiled 4gl specific source code
  • <dirname>/rds
  • rds specific source code
  • <dirname>/a4gl
  • Aubit 4gl specific source code
  • <dirname>/<language>
  • forms, text and help files pertaining to a particular language (eng. ita, etc)
  • <dirname>/objcode
  • .o files
  • <dirname>/pcode
  • .4go files and .o files needed for the runner
  • <dirname>/etc
  • shell scripts, release notes, sql files, etc

    The only exception to this scheme is ierrl.4gh, a 4gl include file that contains text constants related to error handling (I've preferred to string error handling related text to the application, rather than put it in a file loaded at run time, to be sure the user gets meaningful info should text files be unavailable), which is put (correctly) in the appropriate 4glworks/<language>/directories.

    Function names

    Function names mostly follow a mdl_methodname format for public functions and methodname_mdl for private ones. I've tried to confine private functions to the bottom of each file, but this is not always possible, due to language limitations (eg cursor or prepared statements, which must be defined before they can be used).
    I've tried, with a varying degree of success (I've quickly run out of names!) to use meaningful and consistent names for methods.

    Table and column names

    The naming style used for printer definition tables is code_<tablename> for primary keys, desc_<tablename> for descriptive fields, and link_<linkedtable> for foreign keys.
    Single and multiple selection pick lists (i???h.4gl), as well as the single table maintenance scroller (istbs.4gl) have been written to take advantage of my own naming style, but they can be fed with any select statement.

    Current release notes and documentation

  • readme
  • a copy of this documentation
  • todo
  • all that didn't make it in the distribution
  • fglpp.txt
  • brief documentation of fglpp
  • sqsl.txt
  • documentation of the syntax and features offered by the sqsl scripting language interpreter

    Code compilation tools

    All the tools described below are located on the root directory of the 4glworks distribution.


    Fglpp is a cpp stile preprocessor for Informix-4gl originally written to ease message definition management within 4glworks.


    This is the tool used to build 4glworks applications. Essentially, it is a sh based replacement for make, originally written because AT&T SVR3 make doesn't do file name expansion.


    cbuild [-v][-e|-r][-l language][-f framepath][-s sourcepath][-d destpath] project

    Cbuild makes use of a file named .cbuildrc to store user preferences. This is a list of def=value entries, in which def could be any of:

    AWKthe location of awk
    INFORMIXCself explanatory
    INFORMIXDIRself explanatory
    destbasebase directory for cbuild output
    framepathsee above
    langsee above
    sourcepathsee above

    All of the defs in uppercase can be overriden by defining a correspondently named environmental variable; those in lowercase by command line options, with the exception of destbase which rather than replacing the -d option, complements it: cbuild will install the files in <destbase>/<project name>.

    Linked to cbuild are pbuild, ctest and ptest.
    Depending on the name with which it has been invoked, cbuild will

    cbuild expects to find a script named buildfile in <sourcepath>/<project>. Buildfile is used to

    As of beta 2.0b6, buildfile is no longer a shell script, but a makefile-style dependency specification file, the main differences with makefiles being that

    (the above sums up to the fact that you have to name each and every target application)

    rules have a target and dependencies, but no commands - everything is handled internally by cbuild

    On the other hand, unlike make, it's perfectly fine to exploit pathname or brace expansion when specifying dependencies.
    In this respect, note that pathname expansion support is provided by the shell in use, so please specify dependecies sensibly.

    Cbuild also supports the use of include files, variables, some automatic variables ($@ and $*, target name and stem respectively), as well as predefined variables $(FW)and $(TM) which respectively expand to the path of the applicationframework and the path of the package being compiled, as specified from the command line.
    Note that you don't have to specify source / target / pcode /object code directories, nor object or target file extensions, as this is handled by cbuild.

    Cbuild will also look for an application wrapper named fgwprofilein the etc directories of all the modules specified in the buildfile of the project, and place it in the destination directory.
    If none is found, it will use 4glworks/etc/fgwprofile as a fallback. Upon installation fgwprofile will be renamed so as to match the name of the project and linked (for historic and other practical reasons) to .profile


    Use to build a custom runner for 4glworks applications. The command line syntax is:

    mkfgwgo [-v] [-f framepath] [-s sourcepath] [-llib...] [project list]

    Mkfgwgo will need a function definition file for each of the modules to be linked in the runner to build an appropriate fgiusr.c file. This file is named cfuncs and can either be located in <modulename>/source or <modulename>/rds. The format is simply a line with the function name and the number of parameters accepted for each of the functions added to the runner.
    Mkfgwgo will also access buildfile files in each module directory to determine whether any library should be linked. At present this is done by searching for definitions of a variable namede LIBS.
    The runner produced is installed in $INFORMIXDIR/bin/fgwgo. Name and output directory are not configurable.


    A simple shell script to set a few bits and pieces in the source to match your tool (c4gl/rds) and version.

    4gwDemo reference

    4gwdemo is a demo application for 4glWorks. It primarily serves three purposes:

    The following notes give a brief explanation of 4gwdemo usage.

    Menu structure

    Pull down menu "First" is used to choose the current viewer, choose or reload the active set. The following are the available viewers:

    Pull down menu "Second" is used for miscellaneous operation, like changing the display mode for a viewer, enabling a printer, locking or unlocking the database.
    Other commands will appear in the horizontal menu whenever meaningful to a particular viewer.
    Use Ctrl-X to quit 4gwdemo.

    Printer data tables

    For all the above viewers, use

    Pick lists usage

    In all of the above viewers, within input or construct statements, it is possible to display the list of all available choices for a particular field by hitting Ctrl-B. Upon showing up, the pick list will position the cursor on the row that best matches the contents of the field, be it a code, or the relative description. Try the following, and things will become a bit more clear:

    Error log

    This just shows the application error log for 4gwdemo. Hopefully, it should always be empty.
    4glWorks applications error log is a plain 4gl error log with some additions, notably the message chain that lead to the error and the user id.


    Sql Interpreter

    This demonstrates multiple panes usage and the extended sql interpreter capabilities.


    If you have DBA privileges, you can also enter statements that alter or change the current DB. Execution of such statements is subject to confirmation.

    Please address questions or comments to marco greco
    (last updated Mon, 19 April 2004 21:36:43 BST)