Category Archives: Blog

Uniface 10: Code containers, code inheritance and default behavior

One of the many nice, new things about the Uniface 10 Development Environment is the Code Container. Each of your development objects, like components, entities and fields, has its own container that houses all of its triggers, operations and entries, generically called modules.

Uniface 10: Code Containers
Uniface 10: Code Containers

With this new way of organizing code, Uniface 10 provides ProcScript code inheritance in a very clear consistent way; code inheritance is purely on the level of the individual module.

Simply put: a ProcScript module defined at a specific level, overrides any implementation that module might have at a more generic level. Or, from a different perspective: if you do not implement a ProcScript module at a specific level, Uniface will fall back to the implementation of that module at the nearest (inheritance-wise) more generic level.

For triggers, the most generic level is really very generic: it is the built-in default trigger behavior. For most triggers the default behavior is to do nothing, but some triggers do have real default behavior. For example, if you omit an entity’s trigger create at all levels, Uniface still adds an occurrence when the user presses ^ADD_OCC.

The code containers, and the uniform way of code inheritance that comes with them, make Uniface 10 a real pleasure to work with, especially in combination with the Compiled Modules Inspector, which you find at the right-hand side of the Component Editor’s Write Script worksheet. It shows all modules that were compiled into the component, wherever they came from. A simple double-click on any of them moves you right into the code container of the object where that code was defined.

I love it!

Uniface 10: The new procedural declaration of component variables

For Uniface 10 we are constantly reviewing and redefining old concepts, aiming for consistency and reusability while looking for new ways to improve your developing experience and enforce good development practices. This is what the new procedural declaration of component variables is all about.

If you are a developer coming from older Uniface versions you probably are familiar with the ‘Define Component Variable’ form, that allows the creation of variables with component scope and an optional display format. You certainly also know how to declare local variables using the variables block in your triggers and modules. In that case, you might have wondered while accessing the ‘Go To -> Component Variables…‘ menu, selecting the data type from a dropdown list, entering a display format and filling a couple of optional fields… Why can’t I do this from my code, like with local variables?

There are some advantages in the form approach, but the truth is that variables declaration is a fundamental part of coding, as it is the concept of variables scope. It is not only logical but even expected for new developers that variable definitions at component level have component scope. Furthermore, is it a more efficient method of defining and inspect variables. If you think that way, congratulations: You got it! If you are not convinced yet, please keep reading.

In version 10 (10.1.03 and higher) component variables are declared using the ‘variables’ block in the Declarations container of a component. You may declare as many blocks as you want, taking in account that variable redefinitions are not allowed by the compiler. The display format definition takes place -optionally- in the declaration itself, so it looks like this:


variables

DataType {DisplayFormat} VariableName {, VariableName2 ... {, VariableNameN}}

endvariables

The display format is defined using the ‘DIS(<format>)‘ syntax, as it used to be in the ‘Define Component Variable‘ form. You can find extensive documentation about display formats in the Uniface Library. As for the missing fields ‘Description‘ and ‘Comments‘… Well, nothing better than in-code comments to describe our variables.

An actual example of component variables block could be:


variables

string                         vCity, vCountry

string DIS(Mr./Ms. ??????????) vFormattedName         ;- Formatted name for official notifications

date   DIS($NLS(MEDIUM,DATE))  vStartDate, vEndDate   ;- Start/End of contract

float  DIS(9999999P99 US$)     vSalary                ;- Net salary in US dollars

endvariables

Simple, isn’t it? But here is the best part: since component variables are declared procedurally, you can use all the precompiler directives to generate, influence and include component variable declarations. Move your variables block to an include proc to make it reusable. Use the #for directive to quickly generate variables. Make use of definitions to avoid typing complex display formats and ensure consistency between components. Create a snippet library with display formats to quickly insert them into your code.


variables

;- Predefined variable declaration for error handling:

#include MYLIB::ERROR_VARS                 

#for CPTVAR in (NAME,SURNAME,CITY,COUNTRY)

string v<CPTVAR>                      ;- Generate component variables for customer data

#endfor

string <IBAN_FORMAT> vAccount           ;- Predefined printed format for IBAN code (IBAN ???? ???? ???? ???? ????)

endvariables

If you are still hesitant don´t despair: We keep working on great ideas to make code editing faster and easier, as well as providing code and compiled objects information on the editors. But more about that in another blog post…

In the meantime, leave us a comment with your thoughts about the new system! What do you like? What can be improved? How would you make the best use out of it?

Loading loads of Glyphs

As a software developer, every once in a while you find yourself performing a tedious manual task for some hours. As it seems to be something you need to do only once, it does not seem to be worth automating the task. But then later it turns out that you have to do it again. So you make a quick and dirty tool. And then later a colleague has to do the same thing and asks if you have an efficient way of doing it. So you make your tool a bit nicer so people other than you can use it.

For me this happened for the task “load a very large number of image files into Uniface Glyphs”.

So here I present you my tool.

It allows you to select a folder on your disk, then it presents you all the files that are in the folder. You select the files you want to convert and press the button. Occurrences are created in the Uniface Glyph table. Files in an unsupported format are marked yellow, Glyph names and descriptions that are too long are also marked in yellow. Make your changes and press the next button and all your Glyphs are stored and compiled.

Now we can perform a task that used to take hours in a few minutes. (Admittedly you don’t have to do this very often but it is really boring task when you do need to do it!)

The attached Uniface export is for Uniface 9.7. With some adjustments it should also work with older Uniface 9 versions. You need to have a DICT model in your repository (have umeta.xml imported).

http://unifaceinfo.com/download/6470/

Disclaimer:

This tool is not part of the Uniface product and therefore not in support. It also uses some code that is not officially supported and that is subject to change without notice. Please feel free to change the tool to your own requirements.

Glyphmaster

NB:
Have a look at what I did around the selection of the folder:

  • You can either type the name,
  • Or select it from a dialog when you press the button,
  • or select it from your history using the dropdown.

 

HTML5, Javascript and CSS3 training videos for Uniface developers on Uniface.info

The Web capabilities of Uniface have increased year over year. At the moment there are at least six different architectures to integrate Web technology in Uniface or build full Web applications in Uniface.  The HTML5 Widget, Uniface Anywhere and DSPs are obvious examples. In an upcoming blog post, I will go into more detail comparing all options.

Developing modern enterprise applications also requires more Web knowledge for Uniface Developers.

To facilitate this we made a special series of training videos on Web topics for Uniface developers. This series is available on Uniface.info and consists of Introduction and Advanced videos on HTML5, Javascript and CSS3.

The Introduction videos assume zero existing knowledge of the technology. The Advanced Topics can be played in any order and assume the Introduction as pre-requisite. Some videos come with demo material which is available as a download.

To make it easy, I’ve listed all the available videos:

HTML:

Hello World:  http://unifaceinfo.com/html-hello-world/

This session is an introduction to the Hyper Text Markup Language (HTML). We will be creating our first website and use a couple of HTML elements to display some simple text and an image.

Introduction: http://unifaceinfo.com/html5-introduction/

This session discusses the basics of HTML5. It introduces a lot of new HTML elements to give a clear structure to your website. Why are semantics are important?

Canvas: http://unifaceinfo.com/html5-canvas/

This session discusses the HTML5 canvas. We’ll create a simple Uniface graphic by ourselves, and have a look at some more complex examples.

SVG & Multimedia: http://unifaceinfo.com/html5-svg-multimedia/

This session is all about the HTML5 SVG, audio and video elements. We’ll discuss the differences between a Canvas and SVG, and see how we can incorporate a video and mp3 without using Flash or third party libraries.

Geolocation & Storage: http://unifaceinfo.com/html5-geolocation-storage/

This session is about using getCurrentPosition() to obtain the GPS coordinates of the user. Afterwards we’ll store this information in the localStorage object so it is remembered.

Javascript:

Introduction 1: http://unifaceinfo.com/javascript-introduction/

This session is an introduction to JavaScript. Its main characteristics will be discussed, and we will be looking at an example. Moreover we will have a quick glance at its connection with HTML.

Introduction 2: http://unifaceinfo.com/javascript-introduction-ii/

This session is part II of the introduction JavaScript session. We will be looking at some more useful functions, types, objects and arrays.

D3: http://unifaceinfo.com/javascript-d3/

This is a short session about D3. We’ll discuss some use cases and see how it works through the use of some examples. 

JSON: http://unifaceinfo.com/javascript-json/

This is a short session about JSON. We’ll quickly see what it is, how it works, and how you can actually use it.

Advanced Javascript: http://unifaceinfo.com/javascript-advanced/

This is an in-depth session about JavaScript. We’ll go through different ways of using events, and see how the only option of executing things in parallel in Javascript is using callbacks.

 

CSS3:

Introduction: http://unifaceinfo.com/css-introduction/

In this session we’ll explore the new possibilities of CSS3. It provides a lot of new features that make the life of the developer and designer a lot easier.

Advanced CSS3: http://unifaceinfo.com/css3-advanced/

This is a follow-up of the CSS3 – Introduction session. Transformations allow you to modify the appearance of any HTML to your liking. Be it rotated, translated or skewed. Transformations and animations make HTML elements move around and respond to events.

If you have a question about any of the videos just open a topic on the forum.

 

Inheritance: Why Uniface 10 will save developers a lot of time

As many of you may be aware, we have – for some time – been working on the new version of Uniface, v10. As befits a major version increment, there are quite a few changes in the development environment, as well as to some of the concepts of Uniface. Today I would like to describe one such change, that should help to make development more obvious.

Inheritance, from model to component, has always been a cornerstone of developing an application with Uniface. The model contains the global definition and the component the external variation, the external variation taking a higher precedence over the model when coming to compile. Let’s examine this concept in a little more detail in the area of local procs.

Imagine, if you will, that when using version 9 you have entries defined in the Local Procs Module trigger of a modelled field, and that the field is painted on a component. When you compile and run the component, any calls you have made to the local proc will cause you to execute the entry defined in the model. Now, if you were to create an external variation of the proc and run the component again, you would expect external variation to be used. So given this, the external variation wins out over modelled procs, right? Well, no, not quite! If I were to now paint a new modelled field with yet another version of the local proc defined and lower down the compile order of the component, what happens could be seen as unexpected – the modelled proc of the second field would be used. If the order of compile changes, i.e. the second entity is moved on the component paint tableau, the module that is used could change. This was not the intended behavior.

In version 10 the process has been made much easier to understand – the external variation always takes precedence. All model definitions are compiled before the external variations are overlaid. This change will mean that the compilation becomes far more predictable with less “magic” and mistakes.

There has been another improvement in compilation of local procs – they are now overlaid. Prior to version 10 you could have, in the model, many entries defined in a single trigger, and if you wished to make a change to just one of them in the component, you would have to break inheritance to them all. Effectively, you would duplicate your code into each component where this was the case. Although it is possible to simulate the inheritance using included procs, it can take quite a bit of planning to implement. With version 10 you are now able to overlay just a single proc module, leaving the inheritance for all others.

So how does this look in the component editor of version 10? The first thing you will see is that only the external variation code is displayed, not the modelled code. To enable easy navigation to all the code compiled into the component, a Compiled Module Information (CMI) panel has been added to the editor. It shows all modules compiled into the component. Double clicking on a module in the CMI causes a navigation action and you will be taken to to the definition of the code module – opening a new editor (entity, included proc, etc.) if required. This is a big time saver for the developer.