Tag Archives: Uniface 9.5

The Struct and its references


Hi bloggers,

For the ones that do not know me, I’m Gerton Leijdekker, Usability Consultant and Lead Developer for the Uniface product line in the Uniface Lab in Amsterdam. My intention is to blog about technical subjects, so this first blog will be about the Struct.

With Uniface we always try to keep things simple with the intention to keep it a productive tool; don’t bother with complex stuff, simply plug in the features you need, some ProcScript to glue them together, and done. But simplicity also has a downside, because now and then you just need more…

Some features take the enablement approach, where the functionality can be used to solve a wide range of problems. But where simplicity adds limitations, flexibility adds complexity and complex things are most of the time harder to understand. The Struct is one of them: powerful, flexible, useful … but complex.

The Struct is introduced in Uniface 9.5 and can solve a variation of challenges, like data transformations, data communication, and data processing. The Struct has no format limitations and therefore can handle any data format, whether it is Entities, XML, JSON, or your own custom format. But in all cases it helps if you fully understand what a Struct is and how it works.

Currently, I’m working on the new Uniface 10 IDE and we use the Struct for almost everything. It replaces entity, occurrence, list, and xmlstream parameters and is heavily used for data cashing purposes. But although I was involved during the original design of the Struct, now that I need to use it, I still find it a challenging thing to use and it took me some time to fully grasp its concepts. In this first blog, I will focus on its core technical concepts being the Struct itself, the Struct Node, the Struct Variable, and the Struct Node Reference. To me it was very helpful once I fully understood those.

The info in this blog is also being used to update the Uniface Library, but remember, you read it here first. 🙂

The Struct

The Struct is a collection of objects, called Struct Nodes. These Struct Nodes are hierarchically organized, hence the term ‘struct’. Every Struct Node can have i/o refers to 0, 1, or more child Struct Nodes. The Struct always has only one root Struct Node.

The image shows two Structs as the reside somewhere in Uniface memory:

Struct Image 1

The Struct Variable

You can declare a struct variable the way you like any other variables, but unlike to variables of type String, Numeric, or Boolean, the Struct Variable does NOT contain the data itself; the Struct Variable only refers to the struct data that (as said) resides somewhere in Uniface memory. To be more specific, a Struct Variable refers to the root Struct Node of a struct dataset making this dataset the thing we call ‘Struct’.

The image shows two Struct variables referring to the root node of a Struct.

Struct Image 2


A Struct Variable can actually refer to multiple Structs or to none at all.  To be specific, a Struct Variable can refer to 0, 1, or more Structs.

The image shows a single Struct Variable containing 2 references to two Structs.

Struct Image 3

The opposite is also possible: multiple references to the same Struct.

The image shows two Struct Variables referring to the same Struct. One has to refer to the root node, the other refers to some node in the same Struct making it a kind of sub-Struct or nested Struct. More about this construction later.

Struct Image 4


Struct Variable declaration

The declaration of a Struct Variable, does not create the Struct, it only creates a Struct Variable with zero references. This variable can now be used to either create a Struct from scratch or have it referred to an already existing Struct.

The image shows two Struct Variables that do not refer to any Struct.

Struct Image 5


Struct creation

There are two ways to create a Struct.

The first is by making use of the Proc function $newstruct. This Proc function creates a single Struct Node and returns a reference to it. If this reference is then assigned to a Struct Variable, a Struct consisting of a single node, has been created.

The image shows the code used create a Struct with only one node. This Struct is now accessible via the Struct Variable.

Struct Image 6


The second is by making use of the conversion Proc statements like componenttostruct, xmltostruct, and jsontostruct. Maybe more conversion statements will follow in the future. A struct conversion function uses the provided data in some external format and generates a (huge) set of hierarchical related Struct nodes that logically represent the data. The Proc instruction returns a reference to the root node of this Struct which is typically assigned to a Struct Variable. This Struct is now accessible via the Struct Variable.

Struct Image 7


Struct member creation

To create a sub node, or a Struct member, you also use the Proc function $newstruct, but instead of assigning the newly created node to a Struct Variable, you assign it to a member a specified by its name.

The image shows the code used create the initial Struct and then how members are created.

The image also shows how an existing member is assigned to a Struct Variable, creating a sub-struct or nested Struct.

Struct Image 8


Struct deletion

A Struct that is no longer referenced by a Struct Variable, and therefore not accessible, is automatically deleted from Uniface memory.

The image shows that setting “” to the Struct Variable that refers the root node of the Struct will have as a consequence that the Struct will deleted. A Struct Variable running out of scope has the same effect.

Struct Image 9


The image shows that deleting a Struct does not affect any sub or nested Structs. The sub Struct, or nested Struct, has its own variable referring to its root node (this is what makes it a Struct) and therefore is still referenced and not deleted.

Struct Image 10


Struct parameters

Uniface also supports Struct Parameters. The Struct Parameter is like the Struct Variable, it works with references.

Image a Proc function that takes one struct parameter as input, it checks all members of the referenced Struct and returns references to the members that are leaves as Struct out parameter. The image shows the result after calling this function, where myStructVar1 refers to the root node of the Struct and myStructVar2 refers to all leaves in the same Struct as detected by the function.

But more about Struct Parameters next time.

Struct Image 11

That’s it for now, next time more about passing structs by reference and by value. Gerton's Emoticon



What else can you use Stucts for?

There is well deserved interest and anticipation in Uniface 9.6, however, I’m still digesting plenty of new things from 9.5.  In particular, I’ve been studying the use of Structs, and the data transformation statements that go with it.

You may recall that Structs were invented primarily to support the processing of complex data types that are used in Web Services.  However, procedural data transformation has much broader application that Web Services.  So even if you don’t plan to integrate with Web Services any time soon, you might have a good reason to use Structs in your legacy applications.

In 9.5 the focus of the data transformation has been on XML and Uniface component data structures.  XML often appears in the payload of SOAP messages used in Web Services, but it is also transported as separate files, sometimes accompanied by XML Schema files.  Some software routine generated these files and some other routine will read and interpret it.  If you consider that there may be file transfer, polling or messaging functions that support the transport of these XML files, then you could view these XML files as a part of an asynchronous call to a software process.  It just isn’t following a formal API, like Web Services.

So let’s compare 2 ways of getting the same job done.  Imagine that you have to build an office document from a template of some kind (to provide layout and pre-defined styles) and from data that is maintained by your Uniface application.  It doesn’t matter if it’s a spread sheet or a textual document.  I am comparing the use of an API, such as COM objects for Microsoft Office, versus the XML file(s) that is stored within the final office document file (these days, Open Office Org, and Microsoft Office documents, are really zipped archives of other files that contain everything needed to reconstruct the document).

API calls may be the safest way to build such a documents, as vendors will often publish an API, along with promises (usually kept)  to keep the API compatible into the future, whilst being free to change document structures without notice (and so their structure is not often documented).

However, a series of API calls may be difficult to comprehend, as the vendor usually has to keep their interfaces at a high level of abstraction and quite generic.  The sequence of calls may not match the way that you have to process your own application data.  At least there is a formal error processing mechanism, even if you find it difficult to understand.  APIs are also potentially limited to certain platforms, or may not have a function that performs the task that you require.

XML files have an orderly structured composition which can be validated.  With some simple viewing tools, it is relatively easy to deduce a document’s data structure.  Prototyping XML file creation is quick as there is visual feedback on how the results appear.  On the down side, you may have built the document structure apparently correctly, but it may still contain errors that will make the document appear corrupt by the next software routine that processes it.  So testing and debugging may be more difficult.

Making a choice between 2 such approaches is made routinely by developers due to many factors.  Now developers can take into account the new Structs data type and data transformation statements.  After building a spread sheet for a customer recently, I’m considering building a tool to massage my iTunes library using Structs, after all, it’s just organizing your assets via an XML file!


Traveling back to Amsterdam, with a short stop in Boston.

Today was one of those days where we had a customer going through the “whoa” experience again. This is a phenomena that typically occurs with customers who are still working with version 7 of Uniface (yes, they do exist), who think Uniface only has this old Windows 3.1 look and feel, are now suddenly shown a Uniface 9.5 AJAX front-end. And suddenly see for themselves how great looking a Uniface app can be…

Different reactions might follow, varying from utter disbelief through to “whoa, i gotta get me some of that…”. Which happened today again. Another customer migrating to 9 and continuing their mission critical development with Uniface.

Uniface 9.5 Controlled Release

The Uniface 9.5 Controlled Release introduces the new JavaScript API for Dynamic Server Page Components. The API enables you to manipulate Uniface data and execute logic on the browser using JavaScript, or to integrate with any third-party software that has a JavaScript API. The Uniface Lab ensures forward compatibility with newer Uniface versions.

New Functionality: JavaScript API for Rich Internet Applications

Rich Internet Applications provide end–users with the experience of running a “desktop” application in a browser. Typically, Rich Internet Applications are more interactive, more responsive, and more flexible than traditional web applications. To make this interactive experience possible, Uniface 9.4 introduced a new component type called a Dynamic Server Page. Dynamic server pages enable Uniface developers to build Rich Internet Applications using their existing Uniface knowledge, without the need to learn JavaScript or XML.

But what if you require an even better responsiveness of your application? What if you want to reduce the server load by avoiding unnecessary server roundtrips so you can serve more clients with the same server environment? What if you need to integrate with JavaScript-based 3rd party software? What if, for whatever reason, you want to execute logic on the browser?

Wouldn’t it be cool if you could write your JavaScript in the Uniface Development Environment (thereby making use of inheritance from Application Models, Component Templates, Include Procs, and using Defines) and execute that JavaScript on the browser?

The Uniface 9.5 Controlled Release provides all of this and more—write your JavaScript as if it were a web trigger or a web operation, access Uniface data on the browser, interact with third party software using JavaScript, create and delete occurrences in the browser.


Feedback on the Uniface 9.5 Beta can be shared at the beta discussion forum on www.uniface.info

Registration for the release can be done here:  http://frontline.compuware.com/apps/beta/register/uf_beta.aspx

You can report product issues in the usual way on Frontline, using the dedicated Uniface 9.5.CR product entry. The Amsterdam development team will actively monitor incoming CR calls and contact you if required.

Minimum Requirements

To qualify for the Controlled Release, you need to be a current and knowledgeable customer of Uniface, able to install the Controlled Release product in a timely manner and willing to provide feedback to ensure testing of the new features.

Operating System Support

The Controlled Release is supported for the Windows operating system and the Solid database.

Browser Support

Uniface 9.5 Controlled Release supports Internet Explorer 7 and 8, Firefox 3.X, and Google Chrome.


July 14th 2010 Report on Uniface Lab

July 14th, 2010 Report on Uniface wish list


On July 9th 2009 the Wishlist application went live. As promised this is the second report on Uniface wishes. Every 6 months the Uniface Lab will publish a report a wish “top 10” and what the plans are to implement wishes in the next Uniface version.

Since the start of the wishlist application in total 138 wishes have been received. The voting mechanism of the Community website has been used to create the following wish “Top 10 July 2010”

  1. (1,165)             Have the possibility to interrupt a Uniface process. 
  2. (-,153)             Reduce unnececessary related entity warning (FireSongKT)
  3. (-,127)                         Advanced String handling methods (GHAN)
  4. (2,145)             Support for Regular expressions (Sochaz)
  5. (9, 124)            Grid dynamic column resize/hide/show/move (addice)
  6. (4, 124)            Code sensitive in UDE (apicaud)3.   
  7. ( 3, 116)           Open Hitlist / Pagination (GHAN)
  8. (5,112)             Color Management in uniface 9.x (gypsilon)
  9. (-,108)                         Ability to use .net forms)
  10. (8,108)             Goto definition for procedure calls and operations (ishankter)

Between brackets previous position and wish rating=number of votes * average rating

As you can see the Uniface areas which are described in these wishes vary a lot. To efficiently work on these wishes we have defined 7 categories which are worked on for the Uniface 9.5 timeframe. Please keep in mind that all this information is presented with the best intentions and no commitments can be derived from this document.

  1. Rich Internet applications. The user experience of Web applications is one of the most important factors why companies are adopting RIA as the standard for Web applications Companies embracing cloud as an emerging platform choose RIA as the most chosen User Interface. The launch of Uniface 9.4 supporting RIA has been very successful and we see many companies are migrating to this version. The first production version of a Rich Internet Applications build with Uniface 9.4 are already live and the work in this area continues.  On the Uniface wishlist we find several wishes already in this category and Uniface 9.5 will show the results of these projects both from a programming side as well as performance measurement, one of the important drivers behind Cloud Computing.  Integration with Compuware’s Gomez, Compuware’s Web Application Performance Management tool, and Uniface is currently being implemented
  2. GUI Enhancements. The majority of Uniface applications is deployed on Windows systems. In the short and mid term future the Windows GUI will still be the most used User Interface for Uniface applications. With this knowledge we have put enhancements in the Windows GUI of Uniface on the second place of Uniface 9.5 projects. In order to efficiently work on enhancements in this area we went through the wishlist application and found that the most requested area in Windows GUI enhancements is the Grid Widget. In total 9 wishes request for Grid Widget enhancements. For many Uniface applications the Grid widget or the Multiple Occurrence List is the central point of end user functionality. For Uniface 9.5 we have defined a special project which focuses on enhancements in this area. During the development process of Uniface 9.5 the implementation of this functionality will depend on the priority set for these requests by the uniface.info members.
  3. Support for Unicode. As Uniface applications are more and more deployed in many different countries, Unicode datatypes have become the standard in many Uniface applications. On customer request Uniface 9.5 will be adding Unicode support for MySQL and DB2. The use of Unicode for these databases will have the same ease of use as the existing Unicode supporting database drivers.
  4. Currency. All 3rd parties like hardware vendors and dbms vendors which are supported by  Uniface continue to release new versions of their products and deprecate existing versions. Many customers have chosen Uniface because it makes upgrades transparent for existing applications. Because of that the Uniface Lab spends a lot of time and effort in keeping combinations of platforms and databases up-to-date. Recently support for Oracle 11g R2 and MSSQL 2008 R2 has been added to the Platform Availability Matrix on Frontline for Uniface 9.3 and 9.4. In the coming months several new combinations of 3rd party software will be added to the PAM.
  5. Database drivers. Several database vendors have extended the support for datatypes in their products and soon will deprecate existing functionality. Updates for MS-SQL and MySQL are being estimated. For MS-SQL the new Max specifier for varchar and support for new DATA datatype is planned
  6. Webservices. With Cloud Computing as a strong emerging technology, the integration between software components is done more and more via Webservices. Uniface supports webservices already since Uniface 8. Since those days Webservices have further matured and as we did with the support for complex data and document literal binding style, webservices functionality will go through a next step. Both support for Soap Header and XML schema are on the list of requests. Both projects are significant steps in following the Webservices standards as defined by WS-I profile. At the moment research and estimation is being done on the implementation of Soap Headers and XSD support.
  7. Maintenance. The work on regular monthly Uniface patches continues. In the coming months patches for Uniface 9.4, 9.3 and 9.2 have been planned. The delivery scheme for patches is fixed and can be found on Frontline.



Parallel to this work the Uniface Lab has also started work on Uniface 10. Uniface 10 is a clear land mark on the horizon which will focus on developer experience and cloud computing. For this purpose internal projects have been started and we aim to share prototypes with the Uniface community as soon as they are in a phase where further input and discussion with our end users is needed. After all we do this work to optimally enable the Uniface community to build applications rapidly.


As you can see the Uniface unit is going full steam ahead with the work on Uniface 9.5 and predictable patch releases.


Kind regards


Ton Blankers


Product Manager Uniface