Blog by Peter Lammersma - 

Recently, a dozen Uniface developers gathered at Uniface headquarters in Amsterdam. Some of them had driven for several hours to be here on time.

What was so important about this meeting? The answer is that these developers represent several organizations with one thing in common: they all trust Uniface for their most vital and business-critical applications. Something else the organizations have in common is that they all want to migrate to Uniface 10. That’s why they sent their developers to learn more about it.

A few weeks earlier, most of these developers had participated in a webinar where I told them about the major changes and enhancements in the latest version of Uniface. So, they had heard and seen a lot about these changes already, but on that particular evening in April it was time for some hands-on experience. As a well-known Uniface expert and business partner, I had been asked to guide my fellow developers through this process, and we had decided that ‘pizza session’ was a good name for it (more about this choice below).

The name reminds me of some evenings in my past. Software, cold pizza, and warm cola; what more does a developer need?

The evening consisted of three parts, starting with an optional slot for configuration support. Beforehand, the participants had received instructions on how to install Uniface on their notebooks and create a development environment. If they had run into problems, they were invited to arrive early so we could help them with the configuration. As luck would have it, someone did show up during this pre-pizza config support part of the evening. No, he didn’t need help, though – he just had a three-hour drive and loved to be on time.

According to Mr. Maslow and his hierarchy of needs  the second part of the evening was the most important. It’s obvious that in 1943, when he published his theory, software as we know it had not yet been invented. Nevertheless, everybody enjoys pizzas. Thirty minutes later, a dozen pizzas had completely disappeared, leaving the same number of developers eager to start.

The third and final part of the evening was the hands-on bit. At the back of the classroom, Ton Blankers, Uniface account manager, and Gerton Leijdekker, software architect, were present to answer any questions I couldn’t handle. I kicked off with some theory – just enough for the participants to get started. For the next two hours, a classroom filled with software developers worked on a couple of assignments.

This pizza session was all about the changes to the Uniface 10 IDE. I can talk for hours about these, but as I was limited to a 30-minute timebox, I focused on the major changes – for instance:

-          The terminology. What is a Main Development Object?

-          … and how is it related to the editors in Uniface?

-          What is the difference between Templates, Objects and Models?

-          … and is this really different from what we are used to?

-          What is the Compiled Modules Inspector?

The assignments were about enhancing the IDE with your own utilities. In three exercises, the developers created User Defined Worksheets and User Defined Menus. They learned how to use the IDE in Uniface 10. But the assignments were also about the changes in the meta dictionary to gain full control over the IDE.

Was it a successful evening? Everybody was able to install and configure Uniface 10 (which takes no more than 5 minutes), the pizzas were great, and everyone finished the exercises. But most importantly, the developers discovered themselves why Uniface 10 is so much better than all previous versions. And now they believe it is time to migrate to version 10.

We at Uniface were more than satisfied with the outcome of the very first pizza session of 2019. The security guys were curious, though: what was everyone so happy about? Mission accomplished.

Why do we call it ‘pizza session’? Uniface is just like pizza. Everybody loves it. It’s convenient. And with the right basis (the bottom), everything is possible. Used as a plural, pizza sessions, it is a reusable concept. Yes, we want to organize these sessions a few times a year. There is so much more to discuss and learn about Uniface. The next pizza session is planned for June.

Blog by Barbara Douma

Since the introduction of Uniface 10.3, we have been rolling out a feature called smart suggestions, which adds search and filtering functionality on the basis of object name and description. This makes it easier and faster to find an object that you want to open, edit, or use in a given context. As you type a keyword or part of an object name, the Uniface IDE provides a list of suggestions for objects that match the provided string and are appropriate to the context.

Smart suggestions were originally introduced on the Main U-Bar in Uniface (see the blog Smart Suggestions in the Main U-Bar of the IDE). Since then, we've added this feature to the Component Editor when editing name-based properties. You get smart suggestions when you:

·       Rename entities, fields, and labels in the Component Editor (

·       Define the Modeled Component and Bound To properties in a derived component (

Now our focus is on the Resource Browser, starting with the Component Editor. As of Uniface, the Uniface IDE provides suggestions in the Model tab, so that you can easily find the modeled entities and fields that you need to use. 

Resource Browser: Model Tab

The Model tab of the Resource Browser has been redesigned. It now includes a U-Bar that can be used to find and filter the modeled entities displayed in the tab. The list of entities includes subtype (specialization) entities. Icons indicate whether an entity is a normal modeled entity ()

or a subtype entity ( ).

To ensure fast performance, a maximum of 50 objects can be displayed. You can override this by clicking Show all, or configure to a different maximum using the  UBAR_RESULTS_MAXHITS logical. 

Suggestions for Modeled Entities and Fields

Instead of browsing through hundreds of entities, just start typing a string that occurs in the object name or description in the Model tab's U-Bar. As you type, the list is filtered to show only matching entities and sub-entities. 

As usual, suggestions are offered in the following order:

1.     Objects whose name starts with the entered text

2.     Objects whose name contains the entered text

3.     Objects whose description contains the entered text

You can scroll through the list of suggestions using the Up and Down arrow keys or the scroll bar. 

To insert an entity into the component structure, highlight the entity in the list, then drag and drop the entity into the component structure (or draw the entity frame for a form or report component.)  

To add the entity's fields to the component structure, you first need to select the entity—highlight the entity in the Model tab and press Enter, or double-click the item. This copies the entity URL to the U-Bar and, by default, displays the entity's fields. (Notice that the fld: code is appended to the URL.)

What if you selected an entity to display its fields before you inserted the entity? No worries. Just right-click on a a field and choose Parent Entity from the context menu.

 The parent entity is then displayed in the Model tab so you can highlight and insert it.

Suggestions for Parent or Subtype Entities

As you saw already, subtype entities are easy to recognize in the Model tab, but you can also find the parent or subtypes of a given entity.

For example, to get the supertype of a subtype entity, right-click the subtype in the Model tab, and choose Parent Entity

You can also use the context menu to show the subtypes of an entity. For example, the following suggestions are shown when you choose Subtype Entities  for the UTREE_PERSON.UTREE entity:

Notice that the ent: object code has been added to the entity URL.

If you now select one of the subtypes, the complete URL, including the supertype is copied to the U-Bar and its fields are displayed: 

Navigation Using the Object URL

If you want to return to the supertype object, you can click on the object's name and press Enter. In fact, each element of the URL is like a button that can be clicked to navigate up the object URL.

When you select an object name, a list of the subobject types is displayed. For entities, these are ent: for subtypes and fld: (the default) for fields.

We hope you will enjoy the Resource Browser improvements that we have introduced so far.

But it doesn't end there! As of Uniface, smart suggestions are provided in Model tab of the Entity Editor when you add modeled entities to a relationship, and in the Project Editor when you add create derived components from a modeled component. The principles and behavior are the same as in the Component Editor.

Blog by Jorge Nuñez-Orellana

Recently, we had the presentations of the first Creative Sprint and let me tell you it was a great success. I’ll start by taking you back in time while sharing what are the thoughts which drive this initiative.

The Uniface’s lab is still a startup, yes! A 35-year-old startup in that sense. As with all startups, we thrive through the innovation that comes from the brilliant minds that continue to form the Lab throughout these years.

When working on technology, one tends to adapt the new high-tech trends to produce business value. This is a creative quirk. This challenge rewards the individual with satisfaction and fulfillment. To maximize the benefit from such experience, one repeats the process with certain periodicity, making it part of the development process.

In general, Agile is associated with a creative/iterative development process, following that line of thought, it is common practice in technology minded organizations to include a moment to trigger the creative spirit and embed it on the execution cycle of the production of software. Additionally, that moment serves as a source of wisdom to individuals who use that time to attempt new ways, find new ideas, discover new possibilities.

At the Uniface Lab, we are no different. Already for a few years, we have been trying to stimulate this inspirational flare in between our regular sprint schedule. To spark imagination a bit more, we have adopted a Creative Sprint; a one-day sprint where the goal is to ignite curiosity, play with new ideas and have fun.

Our creative sprint is also a welcome break in our tight schedule. A break which is an investment too. A break as it allows us to step out of the production harness and an investment because it spawns our technological paraphernalia (ideas and tooling).

As competitive as we are, we want to deliver the outmost in one day, producing great value for our time. To illustrate that, I want to share some of the ideas from the creative sprint:

·       Apply cucumber and selenium to web testing

·       Investigate using JavaScript as the scripting language for Uniface’s ProcScript

·       Prototype a message/service bus

·       Use Node.js as a Web-server for a DSP application

·       Investigate enhancements to our threading model

·       Calling Uniface functions from Python

·       Prototype using regular expressions in ProcScript

·       Prototype porting sources to C++ 11 compatible

·       Entries for field, collection and/or occurrence entries as extensions of only component

The results were astonishing, a lot of enthusiasm and tons of valuable information which serves as food for thought. All in a very short span of time. Besides there is more to come as we get a chance to spend some time on innovation every two weeks. How great is that!


Blog by Jyoti Singh

The purpose of this blog is to inform you about some changes in the way widgets are documented and described.

Widgets are the elements that enable the user to interact with a Uniface application. In Uniface, we recognize two types of widgets:

·       Physical widgets are the implementations that provide the functionality to the user. They vary depending on the underlying GUI technology.

·       Logical widgets are named configurations of the physical widgets. Developers can configure physical widgets to use specific properties/styles to create their own logical widgets.  Consequently, one physical widget can be referenced by multiple logical widgets. The available widget properties are dictated by the physical widget, and it is the physical widget that knows how to interpret properties. Logical widget definitions are defined in the [webwidgets] and [widgets] sections from the initialization file.

The logical widget definitions are available to the Development Environment (IDE), where they are shown in the Widget Type property for entities and fields, allowing developers to select one for use. By default, a Uniface installation provides a default set of logical widgets , but this set can be customized by the developer.

The logical widgets used in the application must also be made available at runtime via the [webwidgets] and [widgets] sections from the initialization file in the runtime environment. Forms, Reports, and Dynamic Server Pages (DSPs) use this mechanism.

With the introduction of the physical widget HTMLINPUT for DSPs, which can be used to specify very different input elements, the emphasis is moving more and more towards the capabilities of the physical widget rather than the logical widget.  To reflect this shift in emphasis, the widget documentation for Uniface 10 has been restructured. It now documents the functionality, triggers, and properties of physical widgets, and describes logical widgets in terms of their purpose, since the functionality and properties can be changed by the developer.

To illustrate with an example:

By default, physical widget HTMLINPUT is mapped to EDITBOX, but HTMLINPUT can also be customized to get a custom Input search field which can set or return the value of the placeholder attribute.

Ini file:


Editbox = htmlinput(html:type=text;detail=dblclick)     

Searchbox = htmlinput(html:type=text;html:size=20;html:placeholder="Type to search")

Above two configurations of same physical widget would result into two logical widgets with different capabilities:

If you are interested to know more about the widgets in Uniface, please visit the online documentation

Blog by Peter Lammersma

What I like and expect in every well-designed system is predictability. Can I find what I am searching for in the expected location? In other words, is the interface intuitive and consistent?

That’s one of the best things about Uniface 10. Having worked with several earlier versions of Uniface, I can confidently say that this latest version’s user interface gives the developer unprecedented levels of consistency, predictability and effectiveness.

Overview of the Uniface 10 IDE

At a high level the IDE can be split into three main sections.

Figure 1 IDE main sections

As shown in Figure 1, these main sections are header, editors and message output. The last section, message output, contains the output of actions performed in the IDE. Pretty clear isn’t it? In this article I want to focus on the other two sections, because these are where the magic happens.

A Uniface developer works in the editors’ section. The IDE contains several editors. Let’s start by understanding these.

Main development objects and their editors

Uniface has introduced the term object in version 10. It’s a general term for the ‘things’ developers create and use, such as projects, components and fields. An object is a way for developers to communicate about their work without the need to bother with implementation details. In the article ‘About templates, models and objects’ I have described this concept in more detail.

Objects can be nested as children and parents. Some objects, such as fields, can only exist as children of other objects. Other objects, called main development objects, can exist without a parent and can have children of their own: examples include modeled entities, start-up shells, and projects

All main development objects have a dedicated editor in Uniface 10. When an object can only exist as a child of another object, that child must be maintained in an editor created for the parent.”. For instance, an entity painted on a component is the child of that component and must be maintained in the parent component’s editor.

It’s important to understand the difference between an entity created in the entity editor, which is called a modeled entity, and an entity that is painted on a component in the component editor, which is called a derived entity.

Uniface has a specific editor for every main development object. In the non-modal development environment, a developer can work on several objects in the same environment. Every open editor is identified by a tab.

Scope of your action

I started this article by talking about the predictability of the IDE. In the previous paragraphs I explained that Uniface has an editor for every main development object. The daily activities of the Uniface developer are actions such as creating new components, modifying properties of objects, writing script code, and compiling components. Some actions will be started from the IDE header, others in the editor section. To find the location of the action you want to do in the IDE, it’s good to consider the scope of your action.

  • Does it do something to exactly one opened object? It will be in the editor of that object.
  • Does your action involve more than one object, or is it not particularly related to an object in In short: The header contains global actions, while the editor contains actions relating to the content of the editor.

A few examples:

Compile all components in the repository. This is an action that is not bound to exactly one opened component. This compile action can be found on the main menu in the header.

Compiling a component. This is an action for an open object in the component editor, so it’s to be found somewhere in the editor. Of course, it is also possible to compile the same component from the compile option in the header. The result is the same.

Export all child objects from a project. The boundary of this action is the project’s content. Therefore, it is to be found in the project’s editor.

You can draw an imaginary line between the header and the editor section. Everything that relates to one particular object is somewhere below that line.


Let’s focus now on this editor section. "Although most editors have been rebuilt in Uniface 10, some of the less commonly used objects – for instance the maintenance of glyphs and keyboard translation tables – still use the U9 editors. As part of Uniface’s continuous delivery, these editors will be migrated to the new structure in the future. Every experienced Uniface developer will recognize the U9 versions immediately though.

The new editors are composed of one or more worksheets tailored to the object they serve. An entity editor consists of different worksheets from those in a component editor. The strength of these new editors is best demonstrated with the component editor. A form component is in other ways similar to a dynamic server page (DSP) – they are both components – but at the same time it is different. The form has a client-server interface, while the DSP has a HTML GUI that can contain JavaScript. Some worksheets are the same, and others differ.

Figure 2 The editor is a collection of worksheets

Every worksheet contains one or more tools. These tools depend on the editor and the worksheet. A typical worksheet composition has a resource browser on the left, the properties inspector on the right, and a large tool pane in the center. It’s in this tool pane the actual editing work is done. In this container the developer can, for instance, edit the script, define the key fields of an entity, or compose the structure of a service component. The general structure in the IDE is: editor à worksheet à tool.

Let’s take the editor shown in Figure 2 as an example. This is the modeled entity editor. The active worksheet is the Define Structure. This worksheet contains three tools. the left pane contains the ‘Resource Browser’, in the middle is the ‘Fields Composer’, and on the right is the ‘Properties Inspector.’

User-defined worksheet

Zooming in on the worksheet tabs, I want to show you something interesting.

Figure 3 The worksheet tabs: my worksheets next to the Uniface defaults

In Figure 3, the Uniface default worksheets are shown and next to them are my own worksheets. In another article on ‘Enhancing the provided toolset’, I described how these worksheets can be added to your preferred Uniface editor(s), to make your work as a Uniface developer even more efficient. The worksheets offer great flexibility and power. In your own worksheet(s), you are not bound to the tool panes Uniface is using, and your actions have unlimited scope. You, the developer, are completely free to add a worksheet that performs actions outside the open object, though it is advisable to take the context of the object into consideration.


The IDE of Uniface 10 has the predictability I expect because it is a consistent implementation of the Uniface development paradigm. Uniface 10 is built by developers, for developers. It makes sense – common sense.

I can talk and write about the IDE for hours, but the best advice I can give is: just use it. I am convinced that you will, just like I do.

Blog by Frank Doodeman

There’s a handy feature in the Quick Search dialog of the IDE’s Code Editors: you can use regular expressions in your Search term.

This blog gives a few simple but useful examples.

Where is my variable assigned a value?

Suppose you have a variable or field named SUM, and you quickly want to find the places where some value is assigned to it by means of an assignment statement. In a ProcScript assignment statement, the variable being assigned to is always at the beginning of the line, and it is followed by a single equal sign followed by whatever value is being assigned to it. Therefore, use this regular expression to find all assignment statements that address variable SUM:


Let’s briefly go through the parts of this regular expression to see how it works:

  • It starts with a caret sign: ^. This matches the start of a line.
  • Then there’s \s*. The \s matches any blank character, such as space or tab, and the * specifies that it matches a sequence of zero or more of them.
  • This is followed by the literal text sum, which matches the string “sum”. By the way, sum matches without taking case into consideration – behavior controlled by the match case button, which is off by default.
  • Then there’s another \s*, matching a series of zero or more blank characters.
  • It ends with a literal =, which matches an equal sign.

Where is my variable used?

To find where your variable SUM is used, use this regular expression as your Search term:


This specifies the literal text sum enclosed in \< and \> characters. The use of \< and \>, which match the start and end of a word respectively, ensures that the expression won’t find strings like SUMMARY, CHECKSUM or CONSUMPTION.

Remove trailing blanks from all lines

You can’t see trailing blanks, but they may still annoy you. With this simple regular expression, you can find them and replace them with nothing:


The \s we saw earlier: it matches any blank character. The + that follows it makes it match one or more of them. The $ stands for the end of the line. Use this regular expression as the Search term in the Quick Search dialog and empty the Replace term field in that dialog (make sure you set the dialog to Replace mode by pressing CTRL+H, or by clicking the down-arrow symbol on the left). Click the All button and voilà: no more trailing blanks in any of your lines.

Consistent use of the Struct arrow operator

You may have a coding convention for Struct member references that specifies that you use the -> operator without surrounding blanks, like this: vStruct->mbr. But suppose you stumble upon a piece of code from a former colleague who liked to have space characters around the arrow operator, like this: vStruct -> mbr. You can easily correct that using the Quick Search dialog and regular expressions. Your Search term should specify that you want to find the arrow operator enclosed in blanks:


Then by simply using -> as your Replace term you can replace all these space-consuming arrow operators by compact ones.

Use the new style of string substitution

In the old days, ProcScript string substitution was done using expressions such as "%%FIELD.ENT%%%", where the initial two percent signs indicate the start of the string substitution and the trailing three percent signs indicate its end. In Uniface 10 (and in recent Uniface 9 versions) you can do this in a better way: "%%(FIELD.ENT)". The double percent sign indicates the start of the substitution; the expression inside the parentheses is expanded and used as the result of the substitution. Not only is this easier on the eye, but it is also more flexible, as you can specify any expression between those parentheses.

Of course, if you encounter pieces of code that use the old-style string substitutions, you will want to replace them with new-style ones. Regular expressions come to the rescue:

The Search term starts with the double percent sign that indicates the start of a string substitution. The [^%"]+ means a series of one or more characters that are not percent signs or double quote characters. This part of the Search term is inside parentheses, because that makes it possible to refer to it in the Replace term – or more accurately, refer to whatever it matches. The regular expression ends with the three percent signs that indicate the end of an old-style string substitution.

The Replace term also starts with a double percent sign, since that is also the start of a new-style string substitution. Next comes an opening parenthesis. In the context of a Replace term, this is a literal character; it has no special meaning. The \1 indicates whatever is matched by the part inside the parentheses in the Search term. Then the Replace term ends, with the literal closing parenthesis.

Now, a single click on the All button replaces all old-style string substitutions with new-style substitutions.

Use special comment markers

In some of our Uniface projects, we use a special comment style – a semicolon followed by a dash – to write comments in our ProcScript code. We do this to distinguish real comments from code that was temporarily commented out by using plain semicolons.

If you encounter a piece of code that you know has real comments, but the programmer did not use the above convention, you can use the Quick Search box and regular expressions to correct this. Specify this as a Search term, to find comments that are not special style:


This regular expression consists of four parts:

  • A caret sign: ^. This matches the start of a line.
  • The first expression inside parentheses: ([^";]*). This matches any sequence of characters that are neither double quotes nor semicolons. It is enclosed in parentheses to make it possible to refer to it in the Replace term. The double quote is specified here because we don’t want to match lines that have semicolons inside hard-coded strings.
  • A plain semicolon character: ;. This indicates the start of a ProcScript comment.
  • The second expression inside parentheses: ([^\-]). This matches a single character that is not a dash. The dash needs to be escaped with a backslash character because, in a regular expression, a dash has special meaning if it is inside square brackets.

Then use this as the Replace term:


This specifies the first matched subexpression – the part of the line that precedes the semicolon; then a semicolon with a dash – the comment indicator that we want to use; and finally, the second matched subexpression, which is the first character that followed the semicolon.

Alert readers might realize that there may be lines with old-style comment that are not caught by the regular expression mentioned here. Which ones? That is left as an exercise for you: please post your answers in the comments section.


The IDE Code Editors are based on the Scintilla text editor, and therefore use Scintilla’s specific regular expression capabilities (in posix mode). On some points, this might slightly deviate from the regular expression syntax that you are used to. For more information, visit

Blog by Peter Lammersma

January, 25 2019

As an experienced software solutions creator (sounds prettier than ‘software developer’, doesn’t it?), I spend most of my time in Uniface’s Integrated Development Environment (IDE). The latest version 10 mentions template, model and object on nearly every editor. I think it’s important to know what they mean and to understand the difference between them. Spoiler alert: it has something to do with the level of abstraction.

Development objects, specialization and generalization


Let’s start with objects. I have been using Uniface to develop and deploy applications for many years and I know the ins and outs of Uniface, but I have never seen something that is called an object. In fact, an object is a generalized term for things you and I work with every day.

Anytime you read the word ‘object’, you can replace it with anything you know in Uniface, like field, entity, menu, property, component, etc. These specializations are implementations of objects and are categorized as development objects. Development objects are created and maintained in the IDE.

Some development objects have parents. For example, a field can never exist without an entity, and it’s impossible to define a menu without a library.

Development objects can also be nested. For instance, a component contains at least one entity, and an entity contains fields. To look at it the other way around, the fields have the entity as their parent and the entity has the component as its parent.

Development objects that don’t have a parent, like components and application shells, are called main development objects. Main development objects have a dedicated editor in the IDE.


In the Uniface world, it’s all about the level of abstraction. Templates and modeled objects help you create your development objects. Templates are used to create both objects and modeled objects. The biggest difference between a template and a modeled object is inheritance. This is shown in Figure 1.

Figure 1 Relationship between template, modeled object, and object

The template is the most abstract level, while an object is concrete.

Anything created from a template has no inheritance from that template. A change in the template does not affect the (modeled) object at all. The (modeled) object is a separate copy from the template.

Uniface delivers a set of templates you can work with, but you can also create your own. In the new Uniface 10 development environment, the first thing a developer does is create a repository that will be based on templates. The first time Uniface is started, the developer must specify and load a set of templates. This can be the default Uniface set or a tailormade set of templates. But once loaded in the repository, they are static: they are not development objects.

Modeled objects are a kind of template, but they are created and maintained in the current development repository. This means they add dynamics to the templates.

A modification made in a modeled object is inherited by an object based on that modeled object. This is the inheritance that we, Uniface developers, have known and used for many years.

Template or model

For us Uniface developers, it’s common practice to define a modeled representation of the structured data with entities and fields. As soon as these modeled entities and fields are ‘painted’ on a component, they become derived entities and fields. We know and trust that all properties and scripts are inherited from the model. That’s what makes Uniface so efficient. And that is why you and I use Uniface.

Let’s picture the template, model and object as layers and forget about the specialization of the objects for a minute.

Figure 2 Template, model and object as layers

As shown in the figure, every object is a copy of a template. The model layer adds inheritance, but this is optional.

Every part of your development object is in fact based on templates. Every component, entity, field, etc. is a copy of a template. If you want to save development time or enhance maintainability, you can add inheritance to properties or coding by adding a modeled object layer for these objects.

From modeled to derived objects

Here’s a small example to illustrate what I’ve just been discussing. An application has a few components and a couple of database tables with fields. From a business perspective, the data is the most important element; the application is there to serve the data. To ensure the consistency of the data, it’s normal for us, as Uniface developers, to define modeled entities. These modeled entities have fields, keys and relationships; all of these are modeled too. This model allows the developer to use the data on components without the need to know anything about the implementation of the database.

This is a major strength of Uniface. Again, as soon as a modeled entity is used on a component it is a derived entity and used fields are derived fields.

In case of the modeled entities and fields, every Uniface developer uses templates and models daily. Uniface 10 has enhanced the use of models through the whole environment. It’s up to the developer to use this concept. Templates and modeled objects are present at nearly every stage of the development process, and they make the lives of developers easier and more efficient.

Using modeled objects as much as possible is a logical move. When you want to take a model-driven approach to Uniface application development, using models is a must!

Blog by Gerton Leijdekker

February, 7 2019

In Uniface 10, developers can open development objects from, among other places, the U-Bar by entering the object's full name or selecting the desired object from a list. For small applications these are very useful options however, for larger applications, having a simple way of searching for objects would improve the user's experience and reduce the frustration of searching through, what could possibly be, a long list.

To improve the user experience and provide a simple way to search for objects, we have added smart suggestions to the main U-Bar.

About Suggestions

Smart suggestions are intended to help enter a value that is relevant in a given context, such as the URL of an object, the value of a property, code, or a new name of an object. They can help with entering correct syntax, as well as with finding objects while entering a URL.

Suggestions are offered as you type. Simply start typing, and based on what you enter, suggestions are offered in a drop-down box below the field. You can quickly accept a suggestion using the down/up keys, then continue to enter more text, or press Enter/Tab to select the value.

The offered suggestions depend on the purpose of the entry field and what you type.

Suggestions in the Main U-Bar

The purpose of the Main U-Bar is to open an object for editing. Object URLs have a defined syntax, so the suggestions offered depend on how much of the URL you have entered or selected.

To start with, you need to enter the code of the main development object. If you don’t know the type code, try a keyword, such as form, service, entity, or include to get suggestions based on the description.

If you do know the code, you can just start typing it, for example cpt for components. In this case, a list of component types is offered.

Use the navigation keys to select the type of object you are looking for and press Enter to select it.

(Of course, the list of available types is small, so the easiest way is just to select the type from the list of suggestions without typing anything. 😊)

Suggestions for Objects

Once you have selected the main object type, you can start typing the name of the object, or a string that occurs in the object name or description. While typing, suggestions are offered. The first item that matches is highlighted.

If there is no exact match, suggestions are provided for items that contain the string somewhere in the name or description.

Depending on your naming conventions, your object names and/or descriptions may contain keywords that represent some functional domain, sub-application, or some sort of category. Such information can be used in the U-Bar to find your objects.

Use the arrow keys to accept a suggestion, and press Enter or Tab to open it. However, if you want to open the object at a specific sub-object, type a forward slash to get the next object type suggestions.

You can then select the sub-object type to get the next suggestions.


If your naming conventions are a bit more complex, you can use wildcards * and ? or Uniface characters profile (Gold+*, Gold+?) to enter a naming pattern. For example, perhaps you have a naming convention for components that uses the first 2 characters to specify a functional domain, followed by 4, followed by 2 characters to specify some functional behavior (browse, maintenance, edit, open, erase, batch, …). You could then enter a string like AU????BR, or *BR to find the matching components.

Smart suggestions

What is considered smart depends on the context. The suggestions at the top of the list are considered most relevant; probably the thing you’re looking for. Does the IDE really know? No, but it does make an educated guess.

In the Main U-Bar, for each object type, suggestions are ordered based on modification date, because you often look for an object you recently worked on.

Once you start entering something after the object type, the suggestions are offered in the following order:

  1. Objects whose name starts with the entered text
  2. Objects whose name contains the entered text
  3. Objects whose description contains the entered text


By default, the number of suggestions offered is limited to 50, which allows the IDE to show suggestions instantly. Depending on the connection speed between the IDE and your Repository, you may want to tweak this number by using an assignment file setting. In practice, if your object is not in the first 50, you will probably make your search criteria more specific.

There are situations where you simply don’t know what you’re looking for—you just want to explore the Repository a bit. For such situations, you can have the IDE show all suggestions, allowing you to scroll through the list of suggested objects using the scrollbar.


We feel this is a really useful feature that helps developers navigate around their application’s sources using Uniface 10.

Blog: Peter Lammersma

Enhancing the provided toolset

The new Uniface 10 IDE (Integrated Development Environment) offers a well-equipped toolbox It provides nearly everything a developer needs to build and maintain software applications. But sometimes you want a bit more or need to add a personal touch to the tools provided.

My toolbox

Every developer uses several tools and utilities to do his/her Uniface work effectively.

These are the ones I can’t do without:

  • Uniface 10 to build web and mobile applications.
  • Notepad++ is the editor for all files I don’t edit with Uniface. It is based on the powerful Scintilla editor.
  • To monitor all communications to and from other applications I use Wireshark. This is also perfect for monitoring network traffic.
  • In addition to Wireshark I use a very old tool called Nettool. This tool is easy to use and perfect for creating an http tunnel.
  • To monitor processes on my computer, Sysinternals Process Explorer is indispensable. The developer of this tool, Mark Russinovich, has created a lot of nice tools. If you don’t know about these, just check them out!
  • A database management tool – the choice depends on the database being used. During development I use SQLite studio, since the repository is stored in a SQLite database.
  • GIT and Sourcetree to interface between my local environment and Gitlab. A modern developer can’t do without version control.

Additional utilities

Most of the time, my work is done in the Uniface IDE. Adding extra utilities was and is very useful. Like most developers, I build my own Uniface utilities. These utilities are components built in Uniface that let you perform actions in the IDE.

The functionality of the utilities I use today is very close to what I have been using for the past few years. In previous versions of Uniface, the additional menu was the place to store additional functionality. Uniface 10 offers two places: User Defined Menus and User Defined Worksheets. The first adds a menu entry in the action or global menu, while the second adds a worksheet to one of the editors.

Using the User Defined Menus or Worksheets is very easy, and powerful at the same time. To use the additional tools I already had in the User Defined Worksheets – the solution I like most – only a few changes were needed, and then I was able to utilise the enhanced functionality Uniface 10 offers. This one-time change is really easy and certainly worthwhile. Your own tools can be integrated into Uniface 10 seamlessly.

I’ll now describe two tools I built a couple of years ago and use now in Uniface 10.

My version control interface

The utility I use every day is a basic version control interface. It consists of a Uniface form to create an export of the object I am working on. With the User Defined Worksheets solution, this form has become an integral part of my IDE. The form with the additional functionality is now (with Uniface 10) a tab in the editor of the object.

Before starting a modification to an object – a component for instance – I open this worksheet and it checks if I have the latest version of the object I am about to change. After my work is done, I open this worksheet again to save the latest version of the object to a file on my computer. The User Defined Worksheet has a default operation, ws_refresh, that is fired when the object is changed. This local copy is created by the $UDE function of Uniface. With the external tools GIT and SourceTree, local versions of the objects are stored in Gitlab.

I have made this additional tool available on every editor in the IDE. Version control is important regardless of the type of component.

My entity utility

Another tool I use adds value in the entity editor. The flexibility of the User Defined Worksheet solution in Uniface 10 allows me to add tooling to specific editors in the IDE. This entity utility provides additional information and actions in the entity editor of the IDE.

It adds a new tab to the IDE to show me where the entity, which is opened in the editor, is used, and allows me to perform actions on that particular entity. Besides an overview of all the relationships this entity has, it shows all the components on which the entity (or a subtype of it) is used. It offers functionality to open related entities and components. It also compiles all related components.

Figure 1 An example of my Entity Utilities worksheet

Information about the Uniface repository can be read in the meta dictionary – nothing new about that. What is new in Uniface10 is that information about the current object (as opened in the current instance of the Uniface editor) is available in the U-Bar. The value of the U-Bar is a parameter of the default operation ws_activate. Opening a component in the corresponding editor can be achieved by calling the operation navigateTo in the IDE APIcomponent IDE_API_1.

Wrapping it up

Uniface makes it very easy to add functionality to the IDE. It is enough to have a Uniface resources file and a logical path in the assignment file to enhance the IDE. Use it to add your own tools or to utilise those of others. That last option is very interesting 😊. I wonder what tools you have created and use?

This is still something I would really love to see added to Uniface: a library to share sources, frameworks, samples, tools and other add-ons. It could even be an add-on to the IDE itself.

On there is already a section called ‘Uniface utilities, add ons and extras’. If you have any Uniface 10 additional tooling you want to share, please send it to and the Uniface Support team will be happy to add it. I look forward your input!”

(Original creator: Gerton)

DSP JS API function: uniface.field.getBoundElement()

Putting application developers in control of the presentation layer

HTML5 already provides a powerful set of form controls out of the box, and its functionality is continuing to grow and mature. To get access to all that functionality, application developers need to be able to interface directly with the controls. Uniface 10.3 Dynamic Server Pages provides exactly that capability.

Before we go into detail, let’s see how Uniface’s support for web technology has evolved over time to give developers more and more control over their applications.

The beginning: Uniface Server Pages

Uniface 7.2 provided our first functionality for the web: The Static Server Page, also known as the Uniface Server Page (USP). USPs enable binding between the Uniface server-side data structure and an HTML client side. They handle communication between client and server in a very simple way: the server generates an HTML page complete with data substituted into the HTML, and the browser simply displays that HTML page. Updates are initiated by the browser via a standard HTML submit, after which the server will load the updates and reconnect them with the back end. After that, the server again generates a full-page response with all changes handled, and the whole process starts again from the beginning.

A leap forward: Dynamic Server Pages

Uniface 9.4 introduced the Dynamic Server Page (DSP) allowing Uniface developers to create rich internet applications (RIAs). The biggest difference between a USP and a DSP is the absence of full-page refreshes in the DSP. Obviously, data is still sent to the server and received back by the client, but instead of the whole page being refreshed, only the affected data is returned and merged into the page displayed in the browser. All communication is handled by the Uniface DSP and programming is as easy as writing some ProcScript in a trigger. In addition, Uniface 9.4 DSPs provide out-of-the-box client-side syntax checking, which, in case of a syntax error, avoids a round trip to the server. A DSP consists of a server part and a client part. The client part has a copy of the component definition, which is what allows the client to perform syntax checking.

Introducing the ability to manipulate client data

Initially, Uniface application developers could write business logic solely for the server, using ProcScript; the client side was closed to them. Uniface 9.5 changed that by introducing the JavaScript (JS) API. Uniface application developers can use this to access the Uniface data structure on the client, and can manipulate Uniface data there using JS, without the need to go back to the server. The JS API provides access to field values, properties, valreps, creation and deletion of occurrences, etc.

Application developers take charge of the presentation layer

With Uniface 10.3, we have now also opened up the presentation layer of the client: the Document Object Model (DOM) layer. Using a simple function, a Uniface data object can now get a reference to its bound element in the DOM layer, allowing Uniface developers to access DOM elements in the context of that field, its occurrences, and its instance. The function is:

uniface.field.getBoundElement(ViewId) From the bound DOM element, it is possible to navigate to sibling and parent elements. In case of an AttributesOnly field, the same technique can be used to navigate to child elements. This gives Uniface developers full control of the DOM, allowing integration of third-party JS libraries that integrate at DOM level.

An example

In the following code example we will use the new JS function to change the default reporting of client side syntax errors. The webtrigger onSyntaxError is the trigger that gets fired the moment the client encounters a syntax error. The default way for Uniface to respond in this situation is to set an error class on the element bound to the field that is in error. CSS would then style it appropriately. The code below overwrites the default behavior and sets the error class to the parent element of the element bound to the field:

webtrigger onSyntaxError
  // Get field in the data structure
  var field = this;
  // Get bound element of field in layout
  var fieldEl = field.getBoundElement();
  // Get parent of element
  var parentEl = fieldEl.parentElement;
  // Set error class on parent element instead of the field element itself
  // Prevent default error reporting   return false;


The getBouldElement() function is simple to use and provides full access to the DOM layer of the browser. It opens up communication with any JS technology that needs to interface on the presentation layer.

Uniface Security

Blog by Jason Huggins

The latest releases of Uniface 9 and 10 mark a significant milestone in the enhancement of security, both under the covers along with new functionality to secure applications.

I believe that in practice all organizations need to protect aspects of business confidentially, competitive edge, adhere to applicable privacy regulations and prevent data theft/manipulation. Protecting data is paramount for practically everyone. It can feel like the wild west at times, with attacks coming from all directions, for example an employee, a contractor/visitor, a cyber-criminal, malware/ransomware, accidental hackers, curious observers… the list goes on! Whether the data breach is internal, external, malicious or accidental, the risk sheould be understood, assessed and addressed. The statistics of count, size and cost to a victim show that global data breaches have been on a continual increase each year. The current average cost of breaches is in the millions of dollars range, with total costs per year globally in the billions. Breach sizes have ranged from tens of millions of confidential records up to many billions of lines of data. Predictions suggest that a clear majority of enterprise traffic will be encrypted throughout 2019. It is important for Uniface to support this, whilst making it an easy as part of the development and deployment platform to utilize.

What is the threat?

There are many threats to data security for which network security exposes a key flaw. There is an inherent weakness in the standard TCP/IP network model and IPv4 because none of the layers include security features as such. The protocols ensure very reliable transmission of data however do not fully ensure data integrity or confidentially.  It is extremely easy to sniff and tamper with the data in real time. But wait, what about IPv6 you may ask? Well IPsec, a security protocol, is built into the IPv6 standard however it is not mandatory. The official launch of IPv6 was in 2012 however IPv4 is still the dominant protocol covering around 75% of deployments. The rate of adoption appears to be slowing however this does not in any way mean that IPv6 will not become the dominant standard, it may just take a little longer than expected. IPSec within IPv6 will not necessarily become the drop-in solution to the security hole. It is still valid to apply alternative or additional mechanisms to secure the transmitted data. The Uniface implementation means that the application can with ease, reliably ensure encryption is applied whatever the underlying IPv’N’ network infrastructure implementation and protocol support may be.

What’s new in network security?

Uniface now has a cryptography layer added to its network stack. The implementation is a TLS layer built on top of the standard TCP driver. The TCP driver itself has been refactored yielding several improvements. The new TLS driver utilises OpenSSL libraries. OpenSSL, often referred to as the

‘Swiss Army Knife’ of cryptography, is well maintained/supported, has excellent platform coverage and is backed by major organizations. It implements both Pre-shared key (PSK) and Asymmetric Certificate/Key pair verification, the later providing greater levels of security. The cryptography methods supported, called ciphers, are those of OpenSSL, however by default Uniface will only list the stronger ciphers. The new driver encrypts the network traffic, including IPv6, between Uniface processes encompassing both shared and exclusive servers. A key feature supported by the TLS driver is ‘Peer Name Verification’, which helps mitigate compromises such as ‘Man in the Middle’ attacks. Configuration is very straight forward matching the typical driver approach, with familiar mnemonics such as ‘tls:’ & ‘USYS$TLS_PARAMS’.

The configuration and various possibilities are well documented in the help.


Security is a shared responsibility spanning development and operations. Being more of configuration exercise, developers will see little change. The extra processing needed to encrypt/decrypt may have an influence e.g. transaction size and client vs server processing could become a consideration. Note: Uniface benchmarks match the published OpenSSL results. Operations should understand security, TLS and encryption, ensuring to pick ciphers that adhere to internal policies whilst maximising performance. The ‘pathscrambler’ is essential and must be used to safeguard the TLS configuration settings.

The TLS driver is simple to use and should be considered an essential priority for most.


by Frank Doodeman

Global Objects

There are many types of Global Objects, like Messages, Global Procs and Keyboard Translation Tables, to name a few. The Uniface 9 IDF and the Uniface 10 IDE provide editors to maintain the definitions of those objects. You could consider those as the definition-time source objects. Successful compilation of those source objects results in compiled objects, their run-time counterparts. The compiled objects are static objects. User applications can use them, but they have no way of changing them. To change them, you must use the editors in the Uniface development environment (the version 9 IDF or the version 10 IDE) to change their source objects, then compile those and make the resulting compiled objects available to the application.

Counter – the oddball

There is one particular type of Global Object that is different from the others: the Counter. Contrary to other Global Objects, Counters are not static run-time objects. Any application can change them through ProcScript. The numset statement creates a counter or re-initializes its value, and the numgen statement increases a counter’s value. Considering this, you may even consider Counters as run-time data rather than run-time objects. To maintain Counters, Uniface 9 offers the Define Counter dialog. This dialog gives the impression that, like for other Global Objects, it maintains source objects. However, it does not. In fact, there are no source objects for Counters. They only exist as run-time objects, in UOBJ.TEXT. The Define Counter dialog acts directly on those run-time objects. If your application uses Counters, be aware of these aspects, and apply extra care when deploying UOBJ.TEXT. Also, users of the Define Counter dialog might just accidentally change the value of a Counter that is being used by an application.

Migrating Counters to Uniface 10

Uniface 10 is straightforward: it simply regards Counters as user data. The one and only way to change them is through the ProcScript instructions that are intended for just that purpose: numset and numgen. There is no dialog that can be used to adjust Counter values. If you already initialize and maintain your application’s Counters purely by means of ProcScript logic, there is no extra effort involved for the migration of Counters to version 10. This logic will continue to work as it did in version 9. If, on the other hand, you use the IDF’s Define Counter dialog to initialize and maintain your application’s Counters, you will need to act. To achieve the same functionality in version 10, you must implement that logic yourself, using the available ProcScript instructions. Also, you will need to apply the same care as you did in version 9, to make sure that UOBJ.TEXT is properly distributed and/or installed. This example auto-increments a counter. If it does not exist yet, it creates it and gives it an initial value: 

  ; Auto-increment counter

numgen “MYCOUNTER”, 1, “MYLIB”

if ($status == <UPROCERR_COUNTER>)

    ; Counter does not exist.

    ; Create it and give it an initial value of 1001.

    numset “MYCOUNTER”, 1001, “MYLIB”

    if ($status < 0)

      message “Error generating sequence number.”

      rollback “$UUU”



      SEQNO = 1001

      commit “$UUU”



SEQNO = $result

commit “$UUU”

Uniface 10.3: the version to go for

In case you’ve missed the summer’s exciting news from Uniface headquarters, Uniface 10.3 has now arrived.

I’ve already been working with this new version for a while, initially using a couple of pre-releases, but then for the past few weeks the live release. This experience has convinced me that Uniface 10, and version 10.3 in particular, is the version the Uniface community has been waiting for. I’m writing this blog post to explain why, and especially to share my experiences with the new IDE.

Background: Uniface 10

Uniface 10 was designed and built based on the wishes of the Uniface developer community. Hundreds of questions and requests from Uniface developers all over the world were taken into account during this extensive design exercise. The result is a complete overhaul of the Uniface development environment. Uniface 10 has a whole new look and feel, comparable with any modern IDE. Although it’s still recognizably Uniface, developers may need a little time to get used to the new version, but in my experience that will be time well spent. There’s no way I’m going back to Uniface 9! A major difference from earlier versions is that Uniface 10 is a non-modal development environment, which means you can work with as many Uniface objects as you like in parallel. Being able to switch between components with just one click makes development easier and more efficient. This by itself is a great reason to start using Uniface 10. \\

Highlights of Uniface 10 

Here are some of the enhancements that you’ll notice immediately when you start using Uniface 10 for the first time:

  • The IDE’s performance has significantly improved, making the non-modal concept a pleasure to work with.
  • The graphical form painter functionality is drastically improved – a strong argument for client/server developers to switch to Uniface 10.
  • Debugging is faster: every error and warning message in the compiler output contains a hyperlink to the relevant line of code.
  • There’s a completely updated and stable meta-dictionary so developers can safely port their existing custom-written utilities to Uniface 10. The additional menu items in previous Uniface versions can be used to launch these utilities.
  • Uniface 10 now also has user-defined menus and user-defined worksheets. My experience shows these are very powerful. Yes, you might need to modify your tools, but again it’s worthwhile.
  • The new Transport Layer Security (TLS) network connector makes the network connection between client and server secure – vital for business-critical applications.

I’ll discuss many of these enhancements in more detail in future posts. As well as all these major improvements, Uniface 10 brings some smaller “nice to haves”. For example, I’m pleased to have the option to set the title bar text of the IDE application window.

Migrating to Uniface The migration process from Uniface 9.7 to Uniface 10 has been run by the Uniface team over and over again. Many huge Uniface 9 customer applications have been migrated successfully to Uniface 10. So for those currently on Uniface 9.6 or 9.7, migration is likely to be a smooth process. If, on the other hand, you are currently considering migrating to Uniface 9.7.05, my advice would be to move directly to Uniface 10 instead because of the advantages described above and (This is also Uniface’s advice) it means one migration rather than two and ensures long-term support. Conclusion: based on my experience, I believe Uniface 10.3 is the version to go for.

Blog: Peter Lammersma

Peter Lammersma is an entrepreneur and IT and business consultant. Peter works extensively with Uniface 10. As a long-serving member of the Uniface community, he’s kindly agreed to give his independent perspective in this blog series.

Do I need to compile this?

(Original creator: theo neeskens)

Over the years many Uniface developers have created tools on top of the Uniface Repository. One tool that has been made by many, is one that looks for "dirty" objects: objects that were modified after they were last compiled successfully. In Uniface 9 such a tool would have been based on comparing the fields UTIMESTAMP (modification date of the source) and UCOMPSTAMP (compilation date of the source) of various Uniface Repository tables. In Uniface 10 this has changed, mainly to align the repository with the export format that has been optimized for version management:

  • The modification date of a development object source is only found in the main object. And yes, it is also updated when you change a sub-object. So if you change a modeled field, the UTIMESTAMP of the entity is updated.
  • The compilation date of a development object is no longer an attribute of the source code. It does not have much value to know when the source was last compiled, if you can't be sure that the compiled object was the result of that compilation. Someone may have copied a different compiled object to the output folder. The only real compilation date is that of the compiled object (file on disk or in a UAR).

Uniface 10.3 is the first release of Uniface 10 that is shipped with meta definitions: the new DICT model is published. So now you can re-engineer the tools that you made for Uniface 9. In order to make it easier to (re)write a tool, the $ude("exist") function has been enhanced to return the attributes of the compiled object (file on disk or in a UAR) such as the modification date.

Compiling objects because their source code has changed

It is not just components that require compilation. There are 14 types of development object that require compilation and generate a file in your resources.  I have attached a sample tool that checks whether these objects are "dirty" and therefore require compilation. The tool gathers the source modification date from main development objects, and the compilation date of the compiled objects. In some cases, one main development object (such as a message library) results in many compiled objects (messages). The tool uses $ude("exist") to check the compilation timestamp of the compiled object and $ude("compile") to compile it. The attached export file contains a full project export, so when you open project WIZ_COMPILE, you will see the whole thing. You can download the export here: [download id="7581"] And here is a file with some test data for each object type: [download id="7585"] You will need the Uniface 10.3 DICT model to compile the tool. The new DICT model for Uniface 10.3 is delivered in umeta.xml in the uniface\misc folder of your development installation.

PLEASE NOTE: The sample tool does NOT take into account that a component may require compilation because a modeled entity or an IncludeScript has changed. See below.

Compiling components because a modeled entity has changed

Please note that the attached sample does NOT check if a component requires compilation because a  modeled entity has changed. If you had this check in your Uniface 9 tooling, you also need to implement it in your new tooling.  A Uniface 9 based example for this issue can be found here: You would need to simplify this for Uniface 10 because the modification date is only on the main development object.

Compiling objects because an IncludeScript has changed

Please note that the attached sample does NOT check if a development object requires compilation because an IncludeScript has changed. To implement this is quite tricky, as you would have to find the #INCLUDES within the IncludeScript code, and handle the fact that they can be nested. To correctly parse all of that might not be much faster than just compiling everything...

AI First

(Original creator: lammersma)

Focus on the right stuff

For a long time ‘mobile first’ was our software developers paradigm. Every new application should not only take the mobile user into account but also focus on mobile use as the primary device. Nowadays, Artificial Intelligence, (AI) is also a subject matter. But what does it mean for developers, and what happened to mobile?

AI first, mobile second?

Mobile is not forgotten. The ‘mobile first’ paradigm was necessary to make the step from desktop to mobile and adapt features of mobile devices. Since mobile devices were put in first place it’s common to design and build from a mobile perspective. Mobile is the new normal, just like desktop was in the 90’s and web (still on desktop btw) in the zero’s. Artificial intelligence (AI) is not new. This in contrast to mobile. Twenty years ago we could only dream about the mobile revolution. What we find normal these days most visionaries didn’t predict a decade ago. But AI is something from the mid 50’s. And from far before that. It’s been in your minds for generations, machines behaving like humans.

Artificial General intelligence (AGI)

There are roughly two categories of AI: applied or general. The last one, Artificial General Intelligence, is used for the general purpose systems that more or less behave like the human brain. These systems can be even better (whatever that might be) than the Human General Intelligence. This is what we think about when we talk about AI. But it’s elusive. Have you seen the movie Her? About a man falling love with his Operating System. This is what we think AI is or should be. Thinking like a human, but without the disadvantages of the human brain (the need for sleep for instance). But it is also the image that scares us most, isn’t it. Computers and robots taking over and making us, humans, superfluous. Sometimes it/IT looks like magic. Do you remember this magician David Copperfield making the Statue of Liberty disappear? We all knew it was an illusion (although we didn’t know how he did it). In 18’s century an automated chess player was invented. A machine that could play chess. Turns out, there was a tiny chess player inside this machine. In the 90’s the development of neural networks where very popular. Computers programmed to behave and learn like the human brain. Finally we had real AI! Very promising, but about a decade later we learned about big data. Why predict the future if you can calculate it?! Google could predict the flu based on the search result. That’s what going on these days. And that’s what makes IT an interesting playground for Uniface.

Artificial Applied Intelligence (AAI)

Systems that replicate specific human behavior or intelligence. It varies from old fashioned fuzzy logic (like the controller of your central heating system and the PLC’s the control the traffic lights in your city) to Machine Learning (you wished the traffic lights were controlled by). It all might look like it’s a kind of intelligence, but most of the time it’s something the developer more or less created. But the reaction started by a certain action is depending on previous results: “Last time you, the user, where satisfied when I did this after you did that, so I am going to do exactly the same.” There is nothing magical about that. That’s combining data, computing power and a bit commonsense. An example where I wish the developer did use AAI. On my phone I have a public transport app. When I type the name of the street where I want to travel to, it shows me all the cities with this street. Of course I can start typing the name of the city, but I want the system to know where I want to go. Since I always use this system within my own city. I expect the system to learn how I use it and show the street in the city where I am on top of the list.

Big data and sensors

Tesla knows how to use AAI. Their autopilot it mostly depending on AAI. Every time something unexpectedly happens the car communicates this to a centralized system. The system learns by comparing the specific situation, the performed actions and the results of these actions. In fact, it’s relatively easy. Only thing the system has to do is decide if the current course is safe. Constantly monitoring all real-time input. On the internet you can find videos about Tesla’s predicting a collision and taking proper actions to prevent it. The autopilot stopped the car, as it should. From a human perspective not a big deal, this is what our brain is doing constantly while we are awake (and even in our sleep). And that is exactly what AAI is all about, replicate a specific part of the human intelligence.

Modern times

Most ‘old fashioned’ developers and probably even the organizations they work for, still want build software that is hardcoded van A to Z. That makes the development process manageable and testable. Software that is supporting the business processes of yesterday. Nowadays users expect software to think with them. Software that supports their wishes and demands of tomorrow. Within a few years they expect their systems to think for them! In modern software development AI must kept in mind. Not every situation can be programmed nor tested. It is not a developer thinking about every possible situation. Software is more then a long list of ‘if then’ statements; it’s less. All it takes, is a database with all possible situations and actions. Every new situation is added as soon as it occurs, updating this system on every possible occasion. The heart of the system consists of algorithms that determine which action is the best option given a certain situation. This is how a chess playing computer beats a human grandmaster without cheating like the machine mentioned above: by playing (and winning and loosing) over and over again and learning from it. And this is how a robot learns itself to walk: by walking, and falling and standing up over and over again. Another example where I want to have more intelligence is my calendar. When I have an appointment I want my calendar software to tell me when I should leave to be on time. Based on my current location, the means of transportation, the traffic, my behavior (I walk fast, but leave always just too late), etc. And I want the software to warn me when a new appointment endangers my schedule for that day.


What makes a programming language suitable for AAI purposes? • AAI is about data. Some of the data is static and stored in a database. With Uniface we can build data intensive applications. That’s where Uniface’s is designed for. It’s technology independent, scalable and very stable.The Uniface programming language is optimized for reading data from and storing it into every common database system. • AAI is about using sensors. Not all data is (relatively speaking) static, some is realtime from sensors or user input. The Progressive Web Apps built with Uniface can use every hardware feature on mobile devices. And Uniface can even be installed on devices like Raspberry Pi and use every sensor attached to the system. • AAI is also about user input. Uniface supports a wide range of user devices. From the old fashioned desktops to mobile apps on a smartphone. • AAI is about computing power. Applications build in Uniface can be deployed on every mainstream OS. The coding is interpreted efficiently. • AAI is about building clever algorithms. Developers don’t have to worry about OS and database specifics. So they can focus on writing clever software. Building algorithms is something every developer loves! That sounds ideal for Uniface. And it is! I am very curious about your first AAI applications! For samples, tools, add-on's, blogs and more, visit