Tag Archives: GUI

Uniface 10: What’s happened since the release?

Back in September 2016 we had quite a major event, Uniface 10 was released with the ability to develop and maintain all forms of Uniface applications – Client Server, Web and batch.

Uniface 10

Since the release, and based on lots of feedback from the early adopters, we have continued to actively enhance the IDE with constant incremental improvements. In this blog post, I would like to share with you what these improvements are as well as what we have planned for the near future.

To start, it is probably a good idea to give some high-level topics we have been concentrating on.


This topic has probably been our primary focus during the continuous updating of v10. We have always had a migration path between Uniface versions automating any updates needed. In version 10 we continue with this concept and as information becomes available, from customers and our own experiences, the migration utilities have been updated to further improve the experience.

Uniface 10: Code migrated from 9 to 10
Uniface 10: Code migrated from 9 to 10
Usability and bug fixing

Performance in large repositories has proven to be an area where we have needed to pay attention and has generated some lively discussions on uniface.info. Although this is an ongoing theme we have already made significant enhancements. The dropdown browse dialogs for the Development Objects (cpt:, ent:, libinc:, etc) will load the information and format the data with considerably less of a delay. Incremental rendering has also been added so that the list becomes available and usable even while extra rows continue to be added. The same techniques and improvements will also be added to the resource browsers in the coming patches.

Uniface 10: Cascading brows dialogs
Uniface 10: Cascading browse dialogs
Embedding the GUI screen painter

Client server development is another area we are enhancing. The first enhancement we are planning and currently working on is embedding the form painter directly into the v10 IDE.

Uniface 10: Embedded form painter taken from a developer's PC
Uniface 10: Embedded form painter taken from a developer’s PC
Runtime enhancements

It is now possible to specify what trigger, accept or quit, will be called when an auto close popup loses focus.

The ability to undeclare a trigger, operation or local proc. This will allow model or previously defined scripts to be excluded from the compile effectively allowing default functionality for a trigger to be re-established.

The ability to call up to a higher-level trigger has been added, this allows such actions as explicitly calling the entity level Detail trigger from the field level detail trigger.

Uniface 10: New popup options
Uniface 10: New popup options

As you can see, we’ve been very busy, and there is a lot more to come.

Uniface 64 bit deployment for Windows

During the deployment session from the Uniface Lectures, we covered Uniface 64 bit deployment for Windows in the morning session (not in the afternoon because it took to much time, the videos are available to watch on our YouTube channel though). 

We had a few really interesting questions, I’ve worked the answers into the text below and I dug up an old posting from the old Frontline site, and used that as the basis. 

The oldest Uniface PAM (Product Availability Matrix) I could find was from Uniface 6.1, and with that old version we  delivered 64 bit support on DEC Alpha hardware with Uniface 6.1. OpenVMS, and DEC Unix ports of Uniface. I remember seeing one of the DEC Unix workstations here in the Amsterdam Lab, running the Motif GUI and thinking how advanced it was, how fast it was and I wanted one. Always dangerous to wish for more, I ended up with a Mac on my desk a week later. 

For a number of releases we focused on Uniface server versions for 64 bit, think IBM AIX, HP-UX, Intel Titanium hardware and so forth.  

It was in 2012 that we delivered a 64 bit Windows server version, delivering it in Uniface 9.5.  

It took us a long time, and to be honest, I recall have a few conversations on the topic over the years, and from an out and out technical perspective, the view was that there were few perceived benefits when compared to the 32 bit version to justify the investment to make it happen. I should mention that we had done some clever things with compiler switches to enable memory addressing for a number of releases. 

A Windows 64 bit Uniface client was a different story, and was quite a significant project.  Clearly there were overlaps with the Windows Server (technically they share a lot of common source), but the GUI layer needed a lot of work. We had to refactor a lot of code, as we had a lot of legacy (technical debt) from older versions of Uniface. The name Uniface originated from Universal Interface, and it was possible to develop one Uniface app and deploy it on those old GUI platforms which we used to support thanks to the Uniface specific widgets such as the unifield.  (I’m sure some of us who have been around Uniface for a long time remembers Uniface on Mac, Motif, OS/2 and Windows 3.x.)  There was a lot of old code to clean up and/or remove, and we also have to keep those legacy widgets operational. 

A few additional challenges included our use of automated test tools which didn’t support 64 bit platforms, which also forced our journey to replace them and use Ranorex for our testing. (I’ve covered this in the forums and talked at a few user groups on this topic.)  

We delivered a Windows 64 bit client with Uniface 9.6 in December 2012. We’ve had some good feedback, I recall talking to a customer in the UK, and their comment was that it just seems more ‘fluid’. I talked about this with one of the architects, and the view is that this is probably as a result of the refactoring, possible the additional memory capabilities, but it’s great to get positive feedback. 

It’s available for deployment rather than development, as we have a few external pieces of functionality in the developer, for example the DSP Editor which are not available as a 64 bit product. 

The HTML control we delivered in Uniface 9.6 is also currently restricted to 32 bit. But this will change, it’s based on Chromium (sometimes know as CEF) from Google, and the sources were (finally) updated to 64 bit and we have been working on getting that into Uniface 9.7, and will be part of the Uniface 9.7.02 update which we are finalising. That was a challenge to get working, changes to threading models and API’s meant some rework and lots of testing, but it’s pretty well code complete. 

The Uniface 10 IDE uses that same HTML control extensively, so the move to CEF3, now opens the way to deliver a 64 bit developer. There will be a significant Uniface 10 release in September, but this is something for another posting next month.    


Uniface Modernization: Modern buttons are flat

New button properties are welcome

During the modernization of IDF 9.7 it became clear that 3D buttons could not be used anymore. Windows has gone flat and all the office applications as well. So we needed to address this with some simple properties on the command button widget. The defaults stay untouched even though the new properties make the button more appealing. So we don’t break the look and feel of the existing applications but open the possibilities to a modern user interface.

Properties explained

These new properties make the difference and allow the UNIFACE developer to change the looks of the entire application in a wink. You need to set the button representation to “UNIFACE” is you want to make use of the new properties.


With the new properties we were able to completely mimic the Windows 8 tiles as well as the common flat buttons.

Some examples

In the following example the “Transparent” property is set while the button is placed on a form with a very colorful image. Not very user friendly, since it looks like a label, but it shows the possibilities.

A button with transparency set to TRUE.


The following table shows a button with an image which is styled in different ways:


New property value


During the modernization of IDF we missed the option to create big buttons with an image big enough to fill up the button. The “imgsize” property has a new value to accommodate the workspace buttons in IDF.


Example the UNIFACE Journey planner

If we start making changes to GUI widgets or the GUI driver, we always look to other applications and try to make the user interface in UNIFACE. For the buttons I took the Android application made by the Dutch national railway company NS. With the new button properties we could mimic the user interface completely. Following picture shows the UNIFACE Journey planner which uses flat buttons.


To make designing the application more easy, I created logical widgets with the necessary properties, so I was able to paint the Journey planner very quickly. Creating the logical widgets was some work but after this you can develop an application following a certain theme. You can paste the following buttons into you usys.ini to get the looks as shown in the sample.






I hope this helps you in creating modern looking UNIFACE applications and modernizing existing applications.

Uniface Lectures Webinar Series: Sharing Technical Information

Uniface Lectures Webinar Series

We are about to launch a new webinar series initiative to help share Uniface technical knowledge called the Uniface Lectures.

Once a month there will be an evening session held here at our office in Amsterdam on a particular topic.  Using the latest version of Uniface we will be showing functionality, tips and tricks with the goal of sharing technical knowledge.

Now obviously this is only useful for customers who are able to get here to attend, so we will also repeat the sessions as online webinars, and finally they will be recorded and posted on YouTube. Different Uniface technical experts will be delivering the webinars and we’ll be doing about one per month making sure to cover both East and West time zones.

At this time,  we have the following topics planned. 

  • February – Modernization
  • March – Deployment 
  • April – JavaScript Integration
  • May – Mobile 
  • June – Integration using REST 

We’ll probably take a break for the summer period, but we then intend to restart the sessions in the fall timeframe with new topics. 

We would be interested in ideas of topics to cover, please add suggestions and ideas below in the comments.  What would you like to see covered? What do you want to learn more about?

Further details, and how to register for the Lectures can be found here.

Uniface Lectures

Styling entities and area frames in Uniface 9.7

In Uniface 9.7 we added powerful options to modernize your Uniface application without having to change your code.

Many applications need to run on many desktops and for our Value Added Resellers it may even run at various customer sites. Sometimes it is even a requirement that these sites use different color settings and logo’s. If you have to maintain this customized look using the Property Forms of the Uniface Development Environment it takes a lot of effort.

In Uniface 9.7 we took steps to make this easier:

  • We added new properties on the entity level that will enable you to make an entity (area) look nice.
  • We added a mechanisme to set these properties for individual entities in the .ini file, so outside of your code.
  • We made all graphical entity properties available for Area Frames too. These are only available  from the .ini file.

Bookstore Form without styling:


Same Form with styling in .Ini file:


The following example shows how areas on a form can be highlighted with a kind of card layout:


The Properties

There are properties for the border, the color, and image for the area frames and entities. Some of them are already exists for Shells, Windows or Entities in Uniface. The new property names “borderradius” and “bordercolor” are taken from the W3C standards on CSS.

Border Properties

You can give your Entity or Area Frame different types of border.

  • Flat
    The border is one pixel in size and falls inside the area frame. This means that fields painted at the inner edge of a frame area overwrite the border. By default the border is darkgray. You can customize a Flat border with the BorderColor and BorderRadius properties.
  • Groove
    A groove border shows an edged border with a width of 2 pixels and falls inside the area frame. There is no gap between the colored area and the border.

The border that you can set in the Form Painter is separate from this and still works as it did. If you have a border in the Form Painter and have specfied the BorderType property, you will see both.

When you have specified BorderType=Flat, you can set the color of the border with BorderColor.
When you have specified BorderType=Flat, you can set BorderRadius to give the border round corners by specify the number of pixels for the radius.
When you specify a DropShadowColor, your frame will be displayed with a shadow effect in the specified color.

Background Color Properties

Defines whether the BackColor is shown as a solid color (BackColorFill=Flat) or as a gradient color (BackColorFill=Gradient). Flat is the default.
When BackColorFill has been set to gradient, the color by default runs from white to the specified background color. With BackColorStart you can make the gradient start from any other color.
When you have specified BackColorFill=Gradient, you can use GradientStart to specify whether you want to start the gradient from the Top (default), Bottom, Left or Right.

Background Image Properties

With BackImage you can specify an image that will be displayed as the background for the whole Entity or Area Frame. (Not per occurrence.)
Set HAlign to Left, Right or Center to position the image horizontally.
Set HScale to a percentage to scale the image. Default is 100 (no scaling is applied).
Set PreserveAspect to True to preserve the aspect ratio of the image. The default is False.
Set VAlign to Top, Bottom or Center to position the image vertically.
Set HScale to a percentage to scale the image. Default is 100 (no scaling is applied).


Attach Property

The Attach property now also works on entity and area frames.
All values (left,right,top,bottom, hmove, vmove, hsize, vsize) are supported. So in combination with setting the attach properties on fields, you can make resizable areas on your Forms:


Setting the Properties

Altough the Entities and Area Frames have the same new properties, there are differences in the ways in which you can apply these properties.

Setting the Properties on Entities

Proc Code
You can set properties on entities using the familiar $entityproperties function. All new properties are dynamic so you can change colors etc. at runtime.

Property Form
For the Entity, some of the properties that are discussed in this blog already exist. You can set them on the Property Form for the Entity in the Development Environment. The really new properties can be set on the More Properties form.

.Ini file
In the .Ini file, the properties for entities can be set in the [entities] section.

Assigning properties to DefEntity applies them to all Entities in your application:


For example, give ALL entities a border:

The practical value of setting the same properties on all entities is quite limited in a real application, so we also made it possible to set the properties in a more precise manner:


For example, give the Customer entity a color on all Forms:

This really allows you to control the look of your application without having to recode.

Setting the Properties on Area Frames

For Area Frames, the properties are exclusively controlled through the .Ini file. You set them in the [areaframes] section.

One option is to assign properties to “Frame”. The name “frame” is a special frame. This one is used for all frames that do not have a name or are not in the list of area frames in the usys.ini. This is necessary to allow an existing application to be “pimped” without renaming existing area frames. In most cases, the area frame does not have a name because the developer never gave it one.


For example make all Area Frames blue:

We also made it possible to set the properties in a more precise manner:


For example give the INFO Area Frame a border on every Form:
Or give all Area Frames on Form CUST001 a shadow:
Or give the INFO Area Frame on CUST001 some properties:

This really allows you to control the look of your application without having to recode.


Named Area Frames
The concept of named Area Frames may not sound familiar to you. In Uniface it always has been possible to rename area frames in the Form Painter, but it had practical use only when printing.

Area frames can have a name, which is used to address them from the usys.ini. The name can be changed in the Form Painter, and does not have to be unique.

In the Form Painter you paint an area frame:
Then right click it:
Then select Rename:
Assuming that we have this in our .Ini file:


When you click OK, you get the following in the GFP:


Attach Property
The widgets inside the area do NOT inherit the Attach property of the area.
So if the widgets need to move with the area, you need to give them an Attach property too.
The properties are ignored when the area frame or entity is printed. The scope is the GUI only.
Color Inheritance
Fields or widgets on top of the areaframe or entity will only inherit the backcolor property value and do NOT take the gradient into account when inheriting the color.
Form Painter
The Form Painter will display entity and area frames with the properties that are set in the .ini file. You will NOT see the effect of the properties set in the More Properties form.


Same Entity, different properties: