Category Archives: Blog

Uniface mobile – Custom Cordova plugin support

Some would have noticed that this week has seen the release of two new Uniface patches – G302 for 9.7.02 and F102 for 10.2.01. Normally I wouldn’t post about a patch, however, this time, there is something new that has been included that I would like to share with you. It is now possible to include custom plugins into your mobile app.

In 9.7.02 we introduced the ability to access the Buildozer online build services to compile iOS and Android apps. Included in this integration was the facility to select, from a predefined list, a number of plugins to be included and made available, in JavaScript, to your DSP application. The latest patches have increased this support to enable you to also include plugins from third parties or ones you have created yourself.

Looking in the development environment with the application shell type set to Mobile you will see it is possible to set the mobile app’s properties. With these patches, a new field has been added to the properties screen that allows you to specify one or more public (git) repository where the plugins reside. Now, with the plugins selected in application startup shell, you can submit your app to be built and, as part of server processing, the plugin will be downloaded automatically and included within your project.

Mobile app definitions
Mobile app definitions screen

As an example, we have been asked for the ability to interface with Bluetooth to print a label on a wireless connected printer. A quick search on Google (for Cordova Bluetooth plugin) offered me several options that seem to fit the bill one of which, picked at random, is If I was to include their repository ( in my Uniface definitions, before building my app, I would be given access to the device’s Bluetooth capabilities using the documented API.

The Uniface G302 and F102 patches also include the latest documentation which has been updated to include this topic.

The new Uniface Integrated Development Environment .. more than just a new term

Uniface 10 is all about the new environment for developing Uniface applications. To underline that, we  have given it a new name: the Uniface Integrated Development Environment, or Uniface IDE.

For thirty odd years, we have referred to our development environment as ‘the IDF’. What does the term IDF stand for? How is IDE different from IDF? Is the difference relevant at all? Here in  the Lab, we use the terms IDF and IDE to make the following distinction:

  • IDE is the development environment for Uniface 10
  • IDF is the development environment for all Uniface 9 versions.

The IDE in Uniface 10 has its own new executable, called ide.exe. You can find it in the common/bin folder.
This new IDE uses a new assignment file, named ide.asn. This file is in the uniface/adm folder.

So, some things have changed, others have not. The logical path to the database that stores the repository is still called $IDF in Uniface 10.

IDE and IDF are totally different applications with their own characteristics and a very different user interface. Added to that: the repository has been changed substantially to cater for new functionality in the IDE. So, it’s important for us to distinguish between IDE and IDF.
The Uniface 10.2 IDE is largely composed of a completely new set of editors. Editors for components, modeled entities and projects, to name a few.
And yes, the IDE still contains a subset of editors that also exist in the IDF – you will find these under ‘More Editors’ in the IDE’s top menu. Over time, the old style editors will be replaced by new style editors, i.e.  IDE style editors

Where does the term IDF come from?

Way back, in the late eighties and early nineties of the previous century, the days of Uniface versions 4 and 5, the Uniface development tool was called Information engineering & Design Facility, IDF for short. Here’s a screenshot of the IDF start screen, taken from the Uniface 5.2 manual (and notice that other terminology has changed over time!) 

Uniface 5.2 Manual
Uniface 5.2 Manual

The name idf was also used for the executable that started the development tool: idf.exe on Windows and VMS, or just idf on Unix.
To use the development tool on Unix in those days, you would typically use the environment variable $idf that was defined by the install scripts. And to keep things simple, a predefined logical database path $IDF is used by Uniface to this very day to define where the repository is stored. 

In later versions the term Information engineering & Design Facility disappeared. We introduced the term UDE, short for Uniface Development Environment. The terms UDE and Uniface Development Environment were used all over the place in the documentation,  but I don’t recall ever having seen the term UDE in the tool itself. The executable that started the UDE was still named idf.exe – we’re talking Windows only in the meantime – and the assignment file for the UDE was still named idf.asn.

Enter the $UDE function in the Uniface Proc language in Uniface 9. A function that helps the developer define custom actions on repository data, including compiling, exporting, importing, and converting. On disk, you will find a file called ude.exe. This executable is not used to start the Uniface Development environment, but is used by the $UDE function. There is no ude.asn file for the ude.exe.

And for completeness sake: for a short period in the Uniface 9 lifetime we used the term Uniface Application Platform Suite, or APSThe APS is the workbench that integrates Uniface application development with the BPM product Uniface Flow. Note that as of Uniface 9.7, Uniface Flow is no longer delivered.

Uniface IDE vs IDF
Uniface IDE vs IDF

Confused? Naah, not anymore, I hope ….


Uniface 10: Code containers, code inheritance and default behavior

One of the many nice, new things about the Uniface 10 Development Environment is the Code Container. Each of your development objects, like components, entities and fields, has its own container that houses all of its triggers, operations and entries, generically called modules.

Uniface 10: Code Containers
Uniface 10: Code Containers

With this new way of organizing code, Uniface 10 provides ProcScript code inheritance in a very clear consistent way; code inheritance is purely on the level of the individual module.

Simply put: a ProcScript module defined at a specific level, overrides any implementation that module might have at a more generic level. Or, from a different perspective: if you do not implement a ProcScript module at a specific level, Uniface will fall back to the implementation of that module at the nearest (inheritance-wise) more generic level.

For triggers, the most generic level is really very generic: it is the built-in default trigger behavior. For most triggers the default behavior is to do nothing, but some triggers do have real default behavior. For example, if you omit an entity’s trigger create at all levels, Uniface still adds an occurrence when the user presses ^ADD_OCC.

The code containers, and the uniform way of code inheritance that comes with them, make Uniface 10 a real pleasure to work with, especially in combination with the Compiled Modules Inspector, which you find at the right-hand side of the Component Editor’s Write Script worksheet. It shows all modules that were compiled into the component, wherever they came from. A simple double-click on any of them moves you right into the code container of the object where that code was defined.

I love it!

Uniface 10: The new procedural declaration of component variables

For Uniface 10 we are constantly reviewing and redefining old concepts, aiming for consistency and reusability while looking for new ways to improve your developing experience and enforce good development practices. This is what the new procedural declaration of component variables is all about.

If you are a developer coming from older Uniface versions you probably are familiar with the ‘Define Component Variable’ form, that allows the creation of variables with component scope and an optional display format. You certainly also know how to declare local variables using the variables block in your triggers and modules. In that case, you might have wondered while accessing the ‘Go To -> Component Variables…‘ menu, selecting the data type from a dropdown list, entering a display format and filling a couple of optional fields… Why can’t I do this from my code, like with local variables?

There are some advantages in the form approach, but the truth is that variables declaration is a fundamental part of coding, as it is the concept of variables scope. It is not only logical but even expected for new developers that variable definitions at component level have component scope. Furthermore, is it a more efficient method of defining and inspect variables. If you think that way, congratulations: You got it! If you are not convinced yet, please keep reading.

In version 10 (10.1.03 and higher) component variables are declared using the ‘variables’ block in the Declarations container of a component. You may declare as many blocks as you want, taking in account that variable redefinitions are not allowed by the compiler. The display format definition takes place -optionally- in the declaration itself, so it looks like this:


DataType {DisplayFormat} VariableName {, VariableName2 ... {, VariableNameN}}


The display format is defined using the ‘DIS(<format>)‘ syntax, as it used to be in the ‘Define Component Variable‘ form. You can find extensive documentation about display formats in the Uniface Library. As for the missing fields ‘Description‘ and ‘Comments‘… Well, nothing better than in-code comments to describe our variables.

An actual example of component variables block could be:


string                         vCity, vCountry

string DIS(Mr./Ms. ??????????) vFormattedName         ;- Formatted name for official notifications

date   DIS($NLS(MEDIUM,DATE))  vStartDate, vEndDate   ;- Start/End of contract

float  DIS(9999999P99 US$)     vSalary                ;- Net salary in US dollars


Simple, isn’t it? But here is the best part: since component variables are declared procedurally, you can use all the precompiler directives to generate, influence and include component variable declarations. Move your variables block to an include proc to make it reusable. Use the #for directive to quickly generate variables. Make use of definitions to avoid typing complex display formats and ensure consistency between components. Create a snippet library with display formats to quickly insert them into your code.


;- Predefined variable declaration for error handling:

#include MYLIB::ERROR_VARS                 


string v<CPTVAR>                      ;- Generate component variables for customer data


string <IBAN_FORMAT> vAccount           ;- Predefined printed format for IBAN code (IBAN ???? ???? ???? ???? ????)


If you are still hesitant don´t despair: We keep working on great ideas to make code editing faster and easier, as well as providing code and compiled objects information on the editors. But more about that in another blog post…

In the meantime, leave us a comment with your thoughts about the new system! What do you like? What can be improved? How would you make the best use out of it?

Loading loads of Glyphs

As a software developer, every once in a while you find yourself performing a tedious manual task for some hours. As it seems to be something you need to do only once, it does not seem to be worth automating the task. But then later it turns out that you have to do it again. So you make a quick and dirty tool. And then later a colleague has to do the same thing and asks if you have an efficient way of doing it. So you make your tool a bit nicer so people other than you can use it.

For me this happened for the task “load a very large number of image files into Uniface Glyphs”.

So here I present you my tool.

It allows you to select a folder on your disk, then it presents you all the files that are in the folder. You select the files you want to convert and press the button. Occurrences are created in the Uniface Glyph table. Files in an unsupported format are marked yellow, Glyph names and descriptions that are too long are also marked in yellow. Make your changes and press the next button and all your Glyphs are stored and compiled.

Now we can perform a task that used to take hours in a few minutes. (Admittedly you don’t have to do this very often but it is really boring task when you do need to do it!)

The attached Uniface export is for Uniface 9.7. With some adjustments it should also work with older Uniface 9 versions. You need to have a DICT model in your repository (have umeta.xml imported).


This tool is not part of the Uniface product and therefore not in support. It also uses some code that is not officially supported and that is subject to change without notice. Please feel free to change the tool to your own requirements.


Have a look at what I did around the selection of the folder:

  • You can either type the name,
  • Or select it from a dialog when you press the button,
  • or select it from your history using the dropdown.