a, an application qualifier, is
ifor modules pertaining to interactive apps
oto batch apps
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
afiapplication framework initialization
dtbmany to many table scroller
errerror logging routines
frmform table maintenance
logerror log viewer
mdlprinter model table maintenance
panmultiple pane support
shlOS related functions
sqlsql interpreter / viewer
stbsingle table maintenance scroller
txttext related routines
t identifies the module type. for code it migth be something like
hhelp pick lists
ifor user input modules
lfor 4gl libraries
cfor c libraries
while forms use
ffor screen forms
wfor window forms
optionally followed by another letter to distinguish otherwise equal file names. Text and help files have no type qualifier.
sh!) indicates an include file of some kind.
|compiled 4gl specific source code|
|rds specific source code|
|Aubit 4gl specific source code|
|forms, text and help files pertaining to a particular language (eng. ita, etc)|
|.4go files and .o files needed for the runner|
|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
mdl_methodnameformat for public functions and
methodname_mdlfor 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).
code_<tablename>for primary keys,
desc_<tablename>for descriptive fields, and
link_<linkedtable>for foreign keys.
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.
|a copy of this documentation|
|all that didn't make it in the distribution|
|brief documentation of fglpp|
|documentation of the syntax and features offered by the sqsl scripting language interpreter|
cbuild [-v][-e|-r][-l language][-f framepath][-s sourcepath][-d destpath] projectwhere
projectis the name of the project to be remade
-voption forces verbose operation
-roption forces an application relink only
-eoption forces a rebuild of the entire project
languageis the language to be used for forms, etc (default
framepathis the directory where 4glworks resides (default
sourcepathis the directory where the modules making up the project reside (default
destpathis the directory where executables, forms, etc will be installed (default is
Cbuild makes use of a file named
.cbuildrc to store user preferences.
This is a list of
def=value entries, in which
could be any of:
|the location of awk|
|base directory for cbuild output|
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 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
(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 (
$*, target name and stem
respectively), as well as predefined
$(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
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.
fgwprofile will be renamed so as to match the
name of the project and linked (for historic and other practical reasons) to
Use to build a custom runner for 4glworks applications. The command line syntax is:
mkfgwgo [-v] [-f framepath] [-s sourcepath] [-llib...] [project list]where
project listis a space separated list of 4glworks modules with c functions
option forces verbose operation
framepathis the directory where 4glworks resides (default 4glworks)
sourcepathis a base directory for all the modules (default is
libis any extra library required to build the runner
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
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
The runner produced is installed in
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.
The following notes give a brief explanation of 4gwdemo usage.
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.
For all the above viewers, use
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
(last updated Mon, 19 April 2004 21:36:43 BST)