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

Leave a Reply

Your email address will not be published. Required fields are marked *

Please fill in the right answer to this question * Time limit is exhausted. Please reload CAPTCHA.