All posts by Alex Besteiro

Software developer for Uniface 10.

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?