All posts by Henk van der Veer

Triggers’ default behavior in Uniface 10

With the release of patch F205 for Uniface 10.2.02,  the Uniface 10 compiler has changed to ensure compatibility with Uniface 9 for triggers having default behavior. This blog explains when and how Uniface handles ‘empty’ triggers and invokes default behavior.

A small subset of the triggers in the Uniface model (*) falls back on default behavior if these triggers do not contain executable code. A typical example is the On Error trigger for a field or entity. If you do not define the trigger, the Uniface run time engine will still invoke default handling for error situations. If the trigger has been defined with executable code, only that code is executed, and the default behavior is suppressed.

(*) see the Uniface documentation, section “Triggers with Default Behavior” for the complete list of applicable triggers.

When does a trigger *not* have executable code and revert to default behavior?

In Uniface 10, default behavior is invoked if any of the following conditions is true:

  • the trigger is not declared at all
  • the trigger declaration contains no executable code
  • the trigger declaration only contains one or more pre-compiler directives that do not result in executable code
  • the trigger is undeclared.

Some examples:

Uniface Trigger

Uniface Trigger

Uniface Trigger

Uniface Trigger

What is the impact of the Uniface Inheritance model, how to restore default behavior?

Behavior defined in code containers is inherited at ‘lower’ or ‘derived’ levels. Examples:

  • a modeled entity subtype and its fields inherit from a supertype and its fields
  • a component can inherit from a modeled component (called component template in Uniface 9)
  • an entity or a field in a component’s data structure inherits from the modeled entity or field.

Inheritance can take place over multiple levels, but that’s beyond the scope of this blog.

In Uniface 10, inheritance of code in containers is module-based. Code is contained in explicitly-declared triggers, entries and operations.  If a trigger is declared again on the inheriting level, that definition takes preference and replaces the definition that was inherited from the higher level.

To suppress an inherited trigger in Uniface 10, use any of the options described above: declare an empty trigger, declare a trigger with comment only, or undeclare the trigger on the lower level. An ‘empty’ trigger or undeclared trigger will fall back on default behavior if that is applicable for that trigger.

The following table shows some examples:

Modeled Field trigger error Component field trigger error Result
not declared not declared Default error handling
trigger error
not declared Default error handling
trigger error
if ($error = 0105)
… some code
return -1
not declared User defined error handling
trigger error
if ($error = 0105)
… some code
return -1
trigger error
Default error handling
trigger error
if ($error = 0105)
… some code
return -1
undeclare trigger error
Default error handling

What has changed since patch F205?

With the solution for Issue # 31689 in patch F205 (Uniface 10.2.02), explicitly-declared triggers that are effectively empty now fall back on default behavior, if that is applicable for that trigger.

Before this patch, an explicitly declared trigger in Uniface 10 without executable code or with comment only would not only break inheritance, but also suppress its default behavior. Prior to F205, the only way to ensure that default behavior was invoked was to not declare the trigger or to undeclare the trigger. In case of inheritance of a trigger from a higher level, the only way to restore default behavior on the lower level was to undeclare the trigger.

What has changed since patch F206?

In patch F206 the automatic migration logic in Uniface 10 was changed to benefit from the modifications in patch F205.

Before patch F206, the migration would attempt to assess whether a trigger container coming from Uniface 9 with potential default behavior contained comment or entry declarations only. If so, the trigger would be commented out or undeclared. This approach was not watertight and had a few disadvantages, like adding code during the migration (‘code pollution’) and causing additional compiler warnings compared to Uniface 9.

When migrating a Uniface 9.6 or 9.7 export file into Uniface 10 after installing patch F206, all triggers, including those with potential default behavior, are migrated ‘as is’.

Patch F205 is compatible with code migrated into a Uniface 10 using a patch prior to F206, i.e. there is no need to redo the migration. However, if you want to benefit from the changes in the migration, you should migrate after installing patch F206 or higher.

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 ….


A toolbox in Uniface 10, anyone?

What’s an engineer without tools? The first hit of a Google search for the phrase “Engineer without Tools” is a quote from Star Trek Deep Space Nine – Millennium Book Three (Inferno): “He was alone and useless, an engineer without tools, … “

Alone and useless … I guess that says it all.

Vice versa: the better the tools, the more efficient the engineer can be. Application developers, software developers, software engineers, they all need tools. Of course, the Uniface Development Environment as we know it in Uniface 9 and before is a very advanced tool already, or a collection of tools. In the Uniface 10 IDE we take that to a much higher level, using the concept of the toolbox.

The next release of Uniface 10, internally named 10.00c, shows the first contours of the toolbox. This release will be used for product demos at User Conferences as of mid-May. And no doubt the toolbox will be featured in the next product update on the Uniface Partners United website.

Each task in Uniface 10 will have its own dedicated toolbox. Visually the different toolboxes look and work the same and they can always be found in the same location: at the left side. A toolbox provides the elements (the tools) that are appropriate for creating content in the editor we’re in: when we model an entity we’ll have a toolbox that enables us to create fields, keys and relationships. The project editor will provide a toolbox for creating project content: the elements to choose from in the project editor’s toolbox may range from a single component to a completely predefined application.

The Component Editor in Uniface 10 has three main tasks, each supported by its own specific toolbox: Define Structure, Write Script and Define Layout. Here’s a preliminary screen shot of the Component Data Structure toolbox:

Henk blog May2

The toolbox allows for multi-select, which makes it easy to pull multiple elements into the editor with just a few clicks. In a superficial test we noted down which steps we needed to create a data structure for a DSP based on a modeled entity.

First of all, it’s much more intuitive to discover what you need, because the toolbox puts it ‘in your face’. But more important, in Uniface 10 we needed less than 50% of the mouse clicks compared to Uniface 9.6 to achieve the same result.

But it’s not limited to these benefits, in fact the sky’s the limit! Engineers can create their own custom toolboxes. Whether as a matter of convenience or as a way to encourage or even enforce standards, e.g. project or organizational standards. Agreeing on standards and guidelines is no longer an exercise on paper, but can actually be implemented through software in an intuitive and consistent manner.

One small step…

Since Neil Armstrong landed on the moon, stating “That’s one small step for (a) man…” the moon’s surface hasn’t changed much. At least, to my knowledge. Maybe a few rocks have been moved, but to me the moon by night still looks the same as back then in 1969.

The difference with the changes in development land could hardly be bigger. The older programming languages aren’t extinct yet, but many new have appeared on the set, including complete frameworks implemented in one or more languages, each with their own API. Back then, say 20 years ago, life was simple.  You learned one language, at school or in your own spare time, and reached a varying degree of expertise in that single language. Maybe you touched a second language at the surface, to make sure you could at least read the statements. But programming in a second language was, well, let’s say a challenge.

It may sound like a memory from past life, but I do remember an annual company kick off meeting by – back then – Uniface Corporation in the US, probably around 1992 or 1993. All sales reps and tech reps came to Alameda, CA for a few days and one of the items on the agenda was a ‘pub quiz’ for the techies. A questionnaire with a dozen or so questions about our infamous Proc Language constructs. Of course, we were all cocky, as a tech support guy (or girl) you wouldn’t see the light of day if you didn’t know the Proc Language manual by heart. It was easier then: we knew one language and we knew it very well, it was still limited in functionality and in syntax.

Today, developers hardly ever work with one single development language. They often find themselves in the middle a Software Development Ecosystem, a virtual working space consisting of a variety of tools: development tools, build tools, test tools, etc. But even merely developing a modern application user interface already involves frequent switching between languages: Uniface, JavaScript, HTML/CSS, maybe even Java…

And then, the modern languages are functionally much richer too. Meaning: more functions, more command statements. But also meaning: sometimes small but sometimes big differences between languages for the same type of constructions. For most humans it’s near to impossible to memorize the exact syntax in each language. Already within a single language the syntax may not be strict, often due to later developments and new insights when enhancing the language.

For example, compare the following two Uniface language constructions that sort of serve the same purpose:

Target = $item(Id, Source)

getitem/id Target, Source, Id

Each time I use one of these statements, I find myself invoking the online Help, simply because I forgot. With or without parentheses? And what’s the order of the parameters again?

Comes the IDE to the rescue… Ideally the language editor in the IDE of your choice provides hints, or even better: a degree of intelligent code completion. It takes away the mental load of memorizing and the nuisance of separately looking it up in the reference documentation. So, where is Uniface’s IDE in that respect? Well, we can’t revert the past: it was never there except the keyword coloring and keyword completion (using Tab and Shift Tab to scroll through a list statements or functions one by one).

Uniface release 10.00b, released internally last week for the purpose of showing at User Group conferences these days, makes the first small step:

Henk blog 1

Yeah! Just what I needed: I can see which parameters are expected. I can see their types, their order. I can see where I am in the construction, i.e. which parameter I’m at. Admittedly, a first small step. But remember how Armstrong started. Many more steps to make, one at a time.

And while we’re at it, you actually see a glimpse of the new Script Editor, with new features like line numbering and code folding:

Henk blog 2

More about that and all sorts of other new stuff in 10.00b in the next blog.

Henk van der Veer

PS: I mentioned Java once, but I think I got away with it all right …

Picking Up Speed

Now that Uniface 10 is presented at user group conferences worldwide, it’s high time to start blogging about this new version. My name is Henk van der Veer, program manager for this new release. And I find myself in good company, in a mix of colleagues with a similar longevity of working for the Uniface product (25 years) as well as brilliant young colleagues, less tainted by Uniface history and crucial to the Uniface IDE modernization. And that’s what Uniface 10 is about: the mix of maintaining its strengths, preserving the customers’ ROI and reshaping the IDE’s User Interface.

So, let’s kick off this blog about Uniface 10.  What, dear reader, can you expect from this blog? I plan to blog on a monthly basis about this project. First of all to keep a finger on the project’s pulse and provide a sneak preview every now and then. But also to share news from behind the scenes that we think is of interest to you, obstacles we’ve overcome with solutions worth sharing.  But be aware: there’s also a zillion things this blog is not. Like, it’s not an alternative for attending the product presentations at User Group conferences and it’s not the channel for formal product announcements or product downloads.

Before we start to look ahead, I have to make up a bit for the recent past. Early September we created a stable code drop, internally named 10.00a. This version was provided to be shown at User Group conferences in the fall of 2013. For the first time we showed actually working software instead of mockups at these conferences. Big deal? Yes, pretty big deal. We were now delivering software that realizes the ideas we’ve been telling you about before.

If you’re only remotely involved with the project, you might think that the project is – finally – picking up speed. Well, if you’ve been involved in a software project of a certain size, you know there’s an unavoidable phase with lots of activity before artifacts become visible. Call it lead time, startup phase, research, whatever you call it: it takes time. We created very detailed mockups of the new Uniface 10 Look and Feel. We used them to develop new ideas, to present ideas to stakeholders, to challenge each other’s ideas. We involved a 3rd party, specialized in ergonomics, to review the future product using these mockups. We did not want them to tell us what the new user interface should be like, but had them challenge us. We had to convince them that the user interface we developed was the best way to discover and apply the strengths of our product.

What does 10.00a bring us? Apart from an extensive new framework (a set of APIs developed in 4GL) that provides and consumes data, that handles exceptions consistently, that controls transactions and enables multiple editors open at the same time (I could go on); version 10.00a shows the contours of what the final product will be. It’s not GA, it’s not eligible for sharing with early adopters, but it does show what the GA product is going to be like. We’re building the real thing and it shows how the Uniface 10 IDE will be a showcase of a modern IDE and a modern Uniface application.

Bluntly spoken, the IDE is just a set of editors. Pretty sophisticated editors, I should add. We started with developing the Component editor. It’s the most encompassing and most complex editor.  The first thing that strikes the eye is the ability to have multiple editors open simultaneously:


In the Uniface 9 IDE and older versions you may not recognize editors as such: the IDE looks like a large set of forms that can be invoked one after another. Editing in Uniface 9 is ‘form based’, and too often does not provide a clear notion of the context. In Uniface 10 the context is always visible. For instance: the component editor immediately shows which tasks belong to creating that component type:


And just like navigating between editors by clicking on a tab you can switch between the tasks for a component. Of course, we only show tasks that apply to a specific component type. For instance, a Dynamic Server Page as shown above has a layout which is maintained on the Design Layout Worksheet. A Service on the other hand does not have a layout:


By the way, did you notice: goodbye to Proc, hello Script! We’re no longer calling the Uniface procedural language ‘Proc’. The language constructs will not change, but we’re calling it Script from now on. We think that’s a better term that has a familiar ring in the industry. I mean, who in the world calls their language Proc? But I admit, the term ‘Proc’ has become embedded deeply after so many years. In the Lab we even use it as a verb: to proc. If you’d make me pay a dime for each time I still say Proc instead of Script, I’d be broke soon.

So, what does the Define Structure Worksheet look like then? It’s no longer limited to just the structure of entities, field and labels like you are used when you create a DSP or USP today, but it provides direct access to some common properties:


At a glance you can see the hierarchical component structure and examine whether elements in the structure inherit from a model or from a template and whether the inheritance is broken. You can even edit an object’s properties in line in this view. But of course, Uniface objects have a lot more properties. These are visible and editable in the same view, in the Properties Pane at the right side:


There’s a lot more to say about 10.00a, but this blog is not intended as a presentation or a course. Todays’ blog was merely intended to provide some context for the next series of blogs about Uniface 10.

Next time I’ll elaborate on what we’re developing right now for the next code drop, 10.00b. Within the Uniface lab we use the agile Scrum methodology. Each development cycle (each sprint), lasts 4 weeks. Every 4 sprints we aim to deliver a code drop that is stable enough and has enough new substance for us to show at User Group conferences and customer visits to the Lab.  We will show version 10.00b at User Group Conferences in the UK, France and Australia and we’ll also run an online session somewhere around April 2014.

See you in a few weeks!

Henk van der Veer