Tag Archives: design

Mobile technology to power evolutionary innovation 

In this blog series I’ve covered how innovation can be evolutionary, but what does this look like in the real world?

Mobile technology is a great example of the power of evolutionary innovation, and is proving to be a major way of doing things better. Although mobile apps may have been just a fun distraction until relatively recently, companies increasingly see them as a way of unlocking their enterprise. In some environments, such as academia, users have already come to expect the applications they use to be accessible via mobile devices – and consumerization means this is increasingly the case across the board. What’s more, provision of mobile support often needs to happen fast.

Mobile evolutionary innovation 

Mobile lends itself to evolutionary approaches

You can add a lot of value by simply delivering existing applications’ business functionality via a mobile device, especially given they are typically always on and at hand 24×7. Porting key business tasks to mobile is a prime example of evolutionary innovation, especially as putting functionality on a mobile device can unlock many more innovative ideas. These could be as simple as capturing expenses on the fly, putting an end to lost receipts and time-consuming monthly admin.

Ideas could also be more ambitious. For example, a retailer could use location data to avoid missed deliveries and present alternative drop-off locations should the customer be away from home. Today, we already see notifications being heavily used to maximize the efficiency of deliveries.

With the right development platform, you can do this without much additional overhead. The team can focus on building good, responsive applications that can be deployed across platforms, whether desktop, web or mobile.

It is worth noting that for mobile apps, you don’t have to deliver the whole enterprise solution, just key processes that are relevant to the mobile platform. For example, in an HR application you can save a lot of time and money by putting holiday or expenses approvals on a manager’s phone. This is far more efficient than checking emails and possibly forgetting to act, as they can do the job with one or two touches in response to a notification.

Mobile promotes innovation

What we’ve just described can be truly innovative and evolutionary because you go back to basics. You start by thinking about what’s going on in a manager’s day and what they need to work smarter. You then enable that vision one bite at a time, reusing functionality you already have.

As well as reusing your existing solutions on mobile, you can also innovate by combining them with other technology. For example, a mobile device can continually gather information about location and other aspects of the user’s situation, presenting the right options when most appropriate. You can take advantage of all this real-time information to make your applications better. For example:

A salesperson could be alerted when they are in the neighborhood of a new lead.

While a shop assistant is talking to a customer, the assistant’s augmented reality glasses could feed live facts about products they’re looking at.

A building automation app could use geolocation information to manage lighting, heating and security as a person navigates the location.

A choice of approaches

Mobile innovation can pay big dividends. How evolutionary it is depends partly on the approach you adopt. Possible approaches range from native device development through to mobile web sites. Each has its pros and cons. By taking a pragmatic view, it is possible to combine the best aspects of different approaches.

A hybrid approach combines native and mobile web development, arguably giving you the best of both worlds. It yields opportunities to reuse much of your current functionality and team skills, while also taking advantage of device features. This opens up many innovative ways to improve user experience and efficiency when using the business application.

This series is based on the paper: Agility and Innovation in Application and Mobile Development.

You can download the paper here.

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.

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:


Modernizing Uniface 9.7: The Buttons

In this final episode of the story about modernizing the Uniface 9.7 IDF in 10 easy steps I will explain how we changed the look of the buttons.

button teaser2

If you want to start reading from the beginning part 1 and 2 of the story can be found here:
The first post was about the changes to the start page.
The second post was about the work that was done to make the screens white.

Again, in theory, it should be possible to do this by just changing a few properties in a configurations file. But as you will see it takes a bit more effort to do it in a nice way in an existing Uniface application. Don’t get me wrong, even with the additional work it still was not much effort to do it.

The small tools that I made to make my life easier are available for download, but:


The tools described in this posting are not supported Uniface software. You can download them and use them, modify to your own taste and use them at your own risk. You need the DICT model to be present in your repository before you can compile and use the tool. Be absolutely sure you have a backup of your dictionary before using any of these tools! You can download them here:


When you make an improvement to these tools that might be useful to the community please share it.

Step 7 Determine types of buttons


Now that we changed the color of the Forms and fixed what was needed for that, we focused on the Command Buttons. The requirement was to use flat buttons.

In theory you would only need to change the properties for the Command Button in the .ini file for that. But we have different types of buttons in the IDF and we do not want to style them all in the same way. So we wanted to split up the Command Button in five logical widgets.

Logical Widgets

The first step was to split all buttons into groups and create logical widgets for them in the .ini file so they can styled as a group. These are the logical widgets that we used for the buttons:

IDFButtonBottom, for the big text buttons at the bottom of Forms


IDFButtonSide, for the big text buttons at the right-hand side of Forms

Nearly the same as the bottom buttons.


IDFButtonSpecial, for the buttons that do not fall in any of the other categories
Most of these buttons are somewhere in the middle of the window and need to look like a Bottom or Side Button. So we set the most common properties here and overrule them in the Forms when needed.


IDFButtonImage, for the very small buttons with an image on them, like the >> button
Here we make the button disappear, leaving just a clickable image.


IDFButtonHeader, for the buttons that form the headers of simulated grids
These buttons are simple Windows header buttons.

Since flat buttons and clickable images may not look clickable to people who are not used to them, we added cursor=uhand to each button so the mouse arrow changes to a hand when you go over a button.


Splitting the Command Buttons in these five logical widgets was a lot of work so I made a tool to assist in this mostly-manual step. I used the tool to query for fields with a Command Button widget, and in another window I looked in the IDF what new logical widget it should be. The main advantage of the tool for this step was making sure that I did not miss any buttons.

The tool is called U97_FRMWIDGETS. You can enter a retrieve profile and then work on the properties of the found painted fields. You can delete a property regardless of its value, or only when it has a specific value. You can also Add (or replace) properties in four ways: apply it to all records, do not replace existing values, only replace existing values, only replace a specific existing value. You can also apply a new widget type to all records.

Step 8 Match modeled widgets with painted widgets


In the previous step we determined what painted button should get which new logical widget. But the Development Environment also uses buttons that are modeled in dummy entities in the application model. We want to give them a new logical widget too.


You would expect that a modeled button is always used for that same purpose. But in an older application, such programming standards have not always been followed. So now one button in the application model needs to be represented by multiple logical widgets. The only affordable solution was to change the logical widget in the model to the one that is most often used for this button in the Forms.


The tool and the SQL that I used for this step was of such a ‘quick and dirty’ quality that I will not share this one with you. But it did the trick anyway, and you can easily come up with something similar (or better!)

Step 9 Set the properties on the painted buttons


We have split the buttons in logical groups by using logical widgets. Now we needed to remove the local properties so they do not override those set in the .ini file.

Widget property inheritance


It would be simple if we could just delete all properties of all buttons, but that was not feasible as there was a mix of properties that should be the same on each button and of properties that are specific for a certain button.


I used my tool U97_FRMWIDGETS from step 7 to remove all properties except ROLE and VSIZE from the IDFButtonsBottom. And I removed all properties except TOOLTIP and VSIZE from the small image buttons. This now allows us to control all other properties from the .ini file.

Step 10 Set the properties on the modeled buttons


For the modeled buttons we also needed to remove many properties. As they often did not have properties on the Form, the properties from the Model took precedence over the .ini file instead.

Widget property inheritance


The challenge was to efficiently change the properties of modeled buttons.


The tool is called U97_MODWIDGETS. It is similar to the tool of step 7, but acts on a different entity of the DICT model. For more details see step 7.



We here at Uniface B.V. have a big Uniface 10 project running to change the architecture of the Uniface Development environment. But we still wanted to do a very small project to freshen up the appearance of Uniface 9 as well. I think we succeeded in that, thereby proving that it is affordable to apply some lipstick to an existing Uniface application.


Making the background of all screens white showed up some things in our GUI that can be improved in the future.

  1. The frames and sizes of our widgets are not fully consistent. That was nicely camouflaged by the grey background of the forms, but it shows more clearly on a white background.
  2. The new entity frame properties work fine and allow you to really spice up your application. We will get a blog post up on this soon. But in a multi-occurrence situation, where the entity is made to look like a grid, there is room for further development. There is no room for the frame, causing some visual imperfections.
  3. We have buttons that used to have an image on them in Uniface 7, but not since then. These are still image buttons. In previous Uniface versions that was not a problem as we used a Windows representation for the buttons and that ignores the image. But in Uniface 9.7 we use flat buttons with a Uniface representation and there the image prevents correct centering of the text. We could not find an affordable risk-free solution within the scope of the project so we decided to deliver with this imperfection in place. We will let you know when we have a good approach for this.

These and some smaller issues have been logged during the project and have been put in our backlog for resolution at a later date according to priority.

I hope these posts on how we changed the look of our Uniface application were useful for you. Have fun modernizing your Uniface application!

With kind regards,

Theo Neeskens

Modernizing Uniface 9.7, Part 2

In my previous post, I started explaining what we have done to give the Uniface Development Environment a fresh look.

The previous post was about the changes to the start page.

This post is about the steps that were needed to make screens white. In theory that can be done by changing just one setting in your .ini file. But in real life there are always some small differences between theory and practise.


The small tools that I made to make my life easier are available for download, but:


The tools described in this posting are not supported Uniface software. You can download them and use them, modify to your own taste and use them at your own risk. You need the DICT model to be present in your repository before you can compile and use the tool. Be absolutely sure you have a backup of your dictionary before using any of these tools! You can download them here:


When you make an improvement to these tools that might be useful to the community please share it.


Step 1: Make the background of all Forms white


Making all Forms white can be accomplished by a simple change in the .ini file. Included in this step is altering the Application Shell, the Menu’s and the Panels so they look nice in combination with the white Forms.




As you can see we made the Application Shell a very light blue for a subtle color difference between the Forms and the Application Shell. The Forms were given a white background. The Menus are now white with a blue selection color and the Panels are white with blue accepts. This was all done with properties that already exist in Uniface 9.6.


In theory changing .ini settings should be enough. But unfortunately a small percentage of the Forms had either an index color or a foreground or background color set. That was never noticed before because these were set to the default grey background and black foreground. So after changing the .ini file these Forms remained grey. The challenge is to find all forms with a color and remove the color with minimal effort.


The tool is called U97_FORMCOLOR. When you press Retrieve it will show all Forms in your dictionary that have an Index color or form property color set. It uses your current settings in the [foreground]/normal and [background]/normal sections of your current .ini file to translate the index color to a foreground and background color.  It will also show what window color you have set in the .ini file. There are buttons to convert RGB to HEX colors and vice versa. It did not add a translation of Web colors as that was too much work and I did not need it. There are buttons to put the Index colors in the Window Properties and remove the Index color. One that only does that when there is no window property color and one that does it always. And there is a button to remove the property color when it is the same as the .ini color. Nothing gets stored until you press the Store button so you can play around a little.

Please feel free to change the tool for your own purposes.

Step 2: Remove the color from the painted entities


After step 1 we saw strange grey blobs on some of our nice white screens.

grey blob

Some of our painted entities had an index color or foreground or background color set, and were painted as markers for referential integrity or other technical reasons. To be precise these only show up when they are painted three or more character cells wide. We needed to remove these colors as well.


The challenge is to find all painted entities on all forms that have a color set and to remove the colors with minimal effort. Using SQL is not an option as the index color for the painted entities is stored in the paint area (FORMPIC).


I build a small tool to search for a painted entities with a color with a few additional buttons to manipulate or remove the color. Since the Index color of a painted entity is stored in the form paint tableau I had some fun deciphering and manipulating that.
The tool is called U97_ENTCOLORFRM. When your press Retrieve it will retrieve all painted entities that have an index color or an entity property color set. On a large dictionary this can take some time as it have to search the paint areas (FORMPIC) for the index colors. All buttons have the same function as the previous tool.

Step 3: Remove the color from the modelled entities


After step 2 we unfortunately still saw grey blobs.
grey blob
Some entities had a foreground or background color set in the Application Model (no index color there), and were painted as markers for referential integrity or other technical reasons. These colors needed to be removed as well.


The challenge is to find all entities in all models that have a color set, and remove it with minimal effort.


The tool is called U97_ENTCOLORMOD. It searches for modelled entities with a color and has a few additional buttons to manipulate or remove the color. It works very similar to the previous tools. The differences are caused by Entities in the Application Model not having Index colors.

Step 4: Visibility of Grids


A Grid always has a white background and on our now white Forms it was not so clear to see what area a Grid was occupying on a Form.
We needed borders around the Grids.

In Uniface 9.7 there are new properties that you can use to give the Grid widget a border:
·         BorderType
·         BorderColor
·         BorderWidth

We want to apply BorderType=Flat and BorderColor=Silver to all painted Grids.


The challenge is to find all painted Grids, and to apply the change with minimal effort.


The tool is called U97_GRIDBORDER. This one was kept very simple. It just retrieves all entities that are painted as Grids and has a button to add properties to them.

Step 5: Multi-occurrence entities


This was an issue that was specific for our project but I have included it since in your application you may want to update properties of non-Grid entities too.

Earlier we removed the color from all entities, but in the Development Environment there are multi-occurrence entities that need to look similar to Grids. Since Grids do not follow the background color of the Form but always stay white we had to make these multi-occurrence entities consistent with that.


Like in Step 4, a white data area on a white form does not look so good without some kind of border. So we wanted to add new properties for the entity frame too.

In Uniface 9.7 there are new properties for the default entity:
·         BorderColor
·         BorderType
·         BorderRadius
·         DropShadowColor
·         BackColorStart
·         BackColorFill
·         GradientStart
·         Attach
·         AttachMargin

We want to set BorderColor=Silver and BorderType=Flat on all non-Grid, multi-occurrence entities.



Finding the all painted entities that are not using a grid widget and are painted with a vertical repetition of occurrences. This information is stored in the form paint. Apply BorderColor=Silver and BorderType=Flat to those entities.


The tool is call U97_MULTI_OCC. When you press retrieve it shows all entities that are painted with an occurrence repetition and that is not a Grid. It can be a bit slow on large dictionaries as it needs to look in the paint area of the Form for each painted Entity. The functionality is simple, just a button to add some properties to all painted entities found.

NB: We are aware that in this first release the frame does not look quite right yet when a multi-occurrence entity is painted to look like a grid, as there is no room for the frame.  An alternative for your application could be to give the entities and the form background different colors.

In the next (final) post I will explain what we did with the buttons.

button teaser