This page provides some useful Uniface hints and tips.
- It is possible to read and update the structure of a form in Uniface proc code without
resorting to 3gl. The positions and sizes of widgets on a form are stored in the Uniface
table UFORM, in the FORMPIC field. The FORMPIC field contains embedded hex
1A characters that cannot normally be directly manipulated in Uniface proc code.
- However, if the Decrypt trigger of FORMPIC is modified to include a “dummy” statement,
such as “$1 = 0” then the FORMPIC is automatically transformed. The hex 1A characters
are replaced. And the resulting text can easily be scanned and updated. Afterwards, the
updated FORMPIC text can be stored back to UFORM, and in the process it will
automatically be translated back to its internal format (including hex 1A characters).
- The form included here as a Uniface export file uses this technique to search a specified
set of forms and replace all occurrences of a label containing given text with some given
- Apart from requiring the definition of the UFORM table (available in the umeta.trx file
provided with Uniface) this form is self contained; it does not use any global objects.
You should be able to import it into a Uniface environment, compile it and then run it
- This form was developed and tested under Uniface 7.2.04 on Windows NT.
- It uses an undocumented feature of Uniface, and as such you use it at your own risk.
There is no guarantee that it will work in future versions of Uniface, or even that it will
work reliably under Uniface 7.2.04.
User Defined Database Drivers
- The code provided here implements a very simple Uniface database driver.
It is based on the information in the Uniface DBMS Driver Cookbook (provided
as dbc.pdf with Uniface) and some experimentation. The example is perhaps not
that useful, but does demonstrate how to construct a database driver.
- This example driver allows any key from the DRIVER_SETTINGS section of
the ASN file to be read (or files, if there are include ASN files). It also allows
any key of any section in the Uniface client INI file to be read (as opposed to
the usys.ini file in the Uniface “bin” directory).
- It uses the Uniface service function udgetasn to read the ASN file(s), and a
combination of UGETPROFILE and GetPrivateProfileString to read the
INI file. Note that Uniface now provides a function which should be used in
place of GetPrivateProfileString called UREADSTRINGSYSSETTING,
however it was not used in this example.
- To use this example driver from Uniface the database driver DLL, “driver.dll”,
must be included on the “demandload” line of the Uniface INI file. If this has
been done then the following Uniface proc code should correctly return the
value of the “USYS$MSS_PARAMS” key from the ASN file(s):
sql "ASN;USYS$MSS_PARAMS", "UD5"
The resulting string is returned in $result, and if there is an error, $status and
$dberror will be set appropriately. Note that it is not necessary to perform
an open or close on the database driver path.
- This example driver was developed and tested using Microsoft Visual C++ 5.0
and Uniface 7.2.04 on Windows NT.
- Some experimentation was required to correctly populate the driver information
(in response to driver request code “I”) and due to this the example driver may
Windows Hook Procedures
- Every window, including the main Uniface window has a window procedure.
This runs constantly in the background and handles windows “messages” that
are continually being sent to that window, for example in response to typing on
the keyboard and mouse movement.
- It is possible to replace the window procedure of any window with a customised
window procedure, which performs some additional processing and then calls the
original window procedure. This process of “hooking” in an alternative window
procedure is sometimes referred to as subclassing. Search the Microsoft web
site for more information.
- This feature of Windows makes it possible to control some of the behaviour of
Uniface that would otherise be out of reach of Uniface proc code. For example,
it can be used to intercept the “WM_SETTEXT” message to change the main
Uniface window title text. Search for “UDLLEVENT” or “WM_SETTEXT”
in the Uniface listserver archives (the older messages) for more information.
- In this example, the window procedure of the main Uniface window is tailored
so that when the development environment log on form appears the operating
system user name is automatically entered. This might be useful if there must be
a single shared Uniface INI file and the users in the development environment
have the same names as the Windows users.
- To implement this function the provided DLL, “hook.dll”, must be included on
the “preload” line of the Uniface INI file. And the following line must be added
to the [application] section of the Uniface INI file to actually activate the feature:
- Further information about creating Uniface DLLs can be found in the
document by Charlton Barreto at the University of Manitoba FTP site, or if
that link fails then at http://www.uug.org/uugusmw/external/3gl/index.htm or
at http://www.mbnet.mb.ca/uug/uugusmw/external/3gl/index.htm. Although
it was written around 1995 for Uniface Six it is still largely relevant.
- This example DLL was developed and tested using Microsoft Visual C++ 5.0
and Uniface 7.2.04 on Windows NT.
- Be warned that the Windows features used by this DLL are not supported
by Uniface, for although the 3gl samples provided with Uniface advocate the
creation of other windows, it is probably a dangerous practice to alter the
Uniface window procedure to intercept its messages.
Return to The Uniface Development Tool