Tag Archives: Windows

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.

When thinking Desktop “first” still matters

By Clive Howard, Principal AnalystCreative Intellect Consulting

A few months back, I registered for Mobile World Congress 2015 in Barcelona. As an Analyst, there is a different registration process to the one used for regular attendees. This is so the organisers can validate that someone is a legitimate industry analyst. As well as entering a significant amount of personal data, additional information such as links to published work and document uploads are also required. Crucially, there are a number of screens to complete the registration and accreditation process. But more to the point, many different types of data must be entered – from single and multiple line text entry to file uploads. Some data (such as hyperlinks) requires cut and pasting.

I’m sure that I could have done this using a mobile phone but it would have taken a long time, been awkward and irritating and probably highly prone to mistakes. In short, I would never have considered doing something like this using my phone. Could I have used a tablet? Without a keyboard and mouse it would have been problematic, especially if the screen is small. Using a tablet only Operating System might also have had its problems in places: such as uploading documents from centrally managed systems. Actually I did use a tablet but one connected to a 20inch monitor, keyboard and mouse and running Windows. In that traditional desktop looking environment the process was relatively quick and painless.

Rumours of the desktop’s demise are greatly exaggerated

It is not just complex data entry scenarios such as this that challenge mobile devices. Increasingly I see people attach keyboards to their tablets and even phones. Once one moves beyond writing a Tweet or one line email many mobile devices start to become a pain to use. The reality of our lives, especially at work, is that we often have to enter data into complex processes. Mobile can be an excellent complement, but not a replacement. This is why we see so many mobile business apps providing only a tiny subset of functionality found in the desktop alternative; or they are apps that extend desktop application capabilities rather than replicate or replace them.

One vendor known for their mobile first mantra recently showed off a preview version for one of its best known applications. This upgrade has been redesigned from the ground up. When I asked if it worked on mobile the answer was no, they added (quite rightly) no one is going to use this application on a mobile device. These situations made me think about how over the last couple of years we have heard relentlessly about designing “mobile first”. As developers we should build for mobile and then expand out to the desktop. The clear implication has been that the desktop’s days are over.

This is very far from the truth. Not only will people continue to support the vast number of legacy desktop applications but will definitely be building new ones. Essentially, there will continue to be applications that are inherently “desktop first”. This statement should not be taken to mean that desktop application development remains business as usual. A new desktop application may still spawn mobile apps and need to support multiple operating systems and form factors. It may even need to engage in the Internet of Things.

The days of building just for the desktop safe in the knowledge that all users will be running the same PC environment (down to the keyboard style and monitor size) are gone in many if not the majority of cases. Remember that a desktop application may still be a browser based application, but one that works best on a desktop. And with the growth of devices such as hybrid laptop/tablet combinations, a desktop application could still have to work on a smaller screen that has touch capabilities.

It’s the desktop, but not as we know it

This means that architects, developers and designers need to modernise. Architects will need to design modern Service Orientated Architectures (SOA) that both expose and consume APIs (Application Programming Interfaces). SOA has been around for some time but has become more complex in recent years. For many years it meant creating a layer of SOAP (Simple Object Access Protocol) Web Services that your in-house development teams would consume. Now it is likely to mean RESTful services utilising JSON (JavaScript Object Notation) formatted data and potentially being consumed by developers outside of your organisation. API management, security, discovery, introspection and versioning will all be critical considerations.

Developers will equally need to become familiar with working against web services APIs instead of the more traditional approach where application code talked directly to a database. They will also need to be able to create APIs for others to consume. Pulling applications together from a disparate collection of micro services (some hosted in the cloud) will become de rigueur. If they do not have skills that span different development platforms then they will at least need to have an appreciation for them. One of the problems with mobile development inside enterprise has been developers building SOAP Web Services without knowing how difficult these have been to consume from iOS apps. Different developers communities will need to engage with one another far more than they have done in the past.

Those who work with the data layer will not be spared change. Big Data will affect the way in which some data is stored, managed and queried, while NoSQL data stores will become more commonplace. The burden placed on data stores by major increases in the levels of access caused by having more requests coming from more places will require highly optimised data access operations. The difference between data that is accessed a lot for read-only purposes and data which needs to be changed will be highly significant. We are seeing this with banking apps where certain data such as a customer’s balance will be handled differently compared to data involved in transactions. Data caching, perhaps in the cloud, is a popular mechanism for handling the read-only data.

Continuation of the Testing challenge

Testing will need to take into account the new architecture, design paradigms and potential end user scenarios. Test methodologies and tools will need to adapt and change to do this. The application stack is becoming increasingly complex. A time delay experienced within the application UI may be the result of a micro service deep in the system’s backend. Testing therefore needs to cover the whole stack – a long time challenge for many tools out there on the market – and the architects and developers will need to make sure that failures in third party services are managed gracefully. One major vendor had a significant outage of a new Cloud product within the first few days of launch due to a dependency on a third party service and they had not accounted for failure.

Tab widget extensions for 9.6.04

The new tab widget also known as the TabEx has got some new properties. This small article shows how they work and what it looks like. The new properties are introduced to allow developers to mimic a kind of browser look and feel whereby tabs can be closed or opened based on events in the programming language. For this purpose we introduced a tab button which lives on top of the selected tab. Some developer talk about a close button but this depends on the programming code in the extended trigger of the Tab.

The UNIFACE lab has chosen to follow the MS Internet explorer look and feel. This means that the button is only shown on the active tab.  There is no standard definition in Windows for showing the button on a tab se we had to choose.

The new properties should be defined in the more properties form.

Property TabButton
A button on top of the active tab is shown when this property is set to true.

Property name: “TabButton”

Values: TRUE | FALSE (default)

The active tab shows a small cross when this property is set. By default the button is a cross with the foreground color of the tab. So it follows the label color. When hovered it shows a small button with a red cross.

Tab Widget Image 1

The lab added some extra properties to allow the 4GL developer to design its own tab button.  By default the tab works and looks nice however a developer who wants to be in control can use the following new properties to design a distinct look.

Property TabButtonImg
Defines the image on top of a tab button.

Property name: TabButtonImg


When a valid image is defined the button will show this instead of default cross. Following image shows the tab widget with the tabbuttonimg=@ball.png and tabbutton=true

Tab Widget Image 2

Property TabButtonImgHover
Defines the image on top of a tab button when the button is hovered by the mouse pointer.

Property name: TabButtonImgHover


Defines the image which is shown when the tab button is hovered.

Extended trigger onTabButton

When the button is clicked the tab widget fires the onTabButton extended trigger. There are no parameters. The developer can use the current field value to act on the active tab.

; -- start triggers for tab widget 
trigger onTabButton

end ; trigger onTabButton

Overview of the sample
Following picture shows an overview of the used tabs in this document and the opened form.

Tab Widget Image 3

Overview of what is Possible with the TabEx Widget

TabEx Widget

The new TabEx widget has so many properties that I thought that it would be nice to have an overview what is possible and what the default behavior of this modern widget is.


The tab widget implementation started in the UNIFACE lab after many requests from customers to have different colors on the tabs. The Windows tab control cannot handle this option. To see whether it was feasible to write a control from scratch I started to program at the max for one hour a day to see whether this would work. After half a year there was something what could be shown to product marketing and so the story started. There was enthusiasm and this caused the start of an official project with extra developers, testers and a technical writer.  During this complete project, even from the trial, I looked at hundreds of tab widgets on the Web and other Windows applications and each time I found something the new tab could not do. The design changed until all possible tabs could be realized. So at the end, almost all possible tab widgets, how strange they may look, can be made with the new TabEx widget. After more than four thousand lines of C++ code with the use of the standard label widget implementation and shared code, the TabEx was born.  This document will show you some examples and gives hints on how it works and what the best approach is to take.

Basic idea of the TabEx

If you do not specify a single property, it just works. It is by default a no brainer.

What is what

The following picture gives an overview of a selection of the properties supported in the new tab widget.

Image Aug 7_1

Who is the boss on a standard tab configuration with an horizontal tab strip?

The text in the label is the boss in all circumstances, this is the information which should be displayed correct and complete. What does this mean? It means that the size of a tab is defined by the length and height of the label text. The bigger the label is, the bigger the tab gets. There is one exception to this. If the tab has the property “imgdefault” set and the image is bigger than the text , the image takes over.

This means we can do a trick with this information

For the images on the tab it is not necessary to be big. If the text defines the size of the tab the image will be stretched. So the following small image:

Image Aug 7_2

Can be used to get green tabs. And you can even make it one pixel in width. That will make it difficult to maintain, but in theory this is possible. And of course you don’t do this when the corners need to be rounded for instance, in this case you make an image which is about the size you need.

The tab will look as follows:

Image Aug 7_3

Here we see that the width has been defined by the label text and the height by the image. So let’s try the following image:

Image Aug 7_4

If we use that in the same tab it will look as follows:

Jasper blog small image

Now the height and the width of the label is bigger than the image and so the label defines the final size.  The label has some default padding around it and this make it look correct.

TabStrip image property

Of course this property is described in the user documentation, but it is always nice to see what you can do with this property.

Look at this image:

Image Aug 7_5

The tabstrip image is the dark blue background. The image default for the tabs is a transparent image. The selection image is the light blue image shown in the selected tab with the label text, “Library”.

Transparent images to make the impossible possible

In the following tab uses a blue circular  PNG image as the default. Red for the selected and green for the hovered tab. As you can see the sky is the limit. You can even make a stack based tab strip and by this place these balls in a column.

Image Aug 7_6

Colors versus images

You can specify an image to be displayed on the tab or use colors. Recommended  is the use of an image when the shape is irregular, or when the texture cannot be met with a color. Otherwise the use of colors is recommended to avoid maintenance overhead with all the different images.

Gradient and default color fill

The following picture shows an accordion type tab with as tab colors “dodgerblue”. The images in front of the labels are defined in the valrep.


Image Aug 7_7

Some examples

The following picture shows a default tabEx widget and a version showing images together with the label text.

Image Aug 7_8

The following picture uses a selection image with a small triangular white area to emphasize the selection. For completeness the image shows a UNIFACE version of the tab and a Microsoft Office version.

Image Aug 7_9

List of recommendations

  • Use colors when possible on the tabs. Use images when shape or a texture is needed.
  • Use light text on dark tabs and even consider a special tab font with bold in it.
  • If you have a common look and feel for tabs, define your own logical tab in the usys.ini.  This makes the styling after the application is released a breeze.
  • Avoid in all circumstances more tabs than the tab widget can show. The tab widget will show scroll buttons but the end user will not have an overview of all possible options.
  • When each tab has its own color and the selection does not stand out, use the “activetablinecolor” property to emphasize the selected tab.