Where to put your code

There's an interesting blog post by Dennis Vorst gone up on the Uniface.info blog, titled Where to put your code.  As the title suggests, it's about which places are best for different types of code, based on their content.  

There are a number of options; conceptual at the entity or field level, locally at the entity or field level, within the component, a local procedure or a global procedure.  All of these have their merits.  

I've posted my response, defending the mighty global procedure, but why don't you have a read and add your opinion in the comments?

Summary: Check out this blog post... http://unifaceinfo.com/where-to-put-your-code

Indirection with dollar registers

Indirection in Uniface is a wonderful thing.  You can populate a local/component/global variable with a field name, and then use indirection to get the field value of the field that the variable references.  You can also use it to set the referenced field to a value, like this...

  fld1 = "fld2"

  @fld1 = "Test"

  if ( fld2 = "Test" )

    ;this will be true

  endif

In this example, using the "@" character to indicate indirection, it's the field which is referenced by "fld1" and not "fld1" itself which is updated.

You can even do recursive indirection, which is very cool!  Not something I've had a need for myself, but very clever all the same.

However, today I was trying to populate a register the same way, using code something like this...

  reg50 = "$50"

  @reg50 = "Test"

  if ( $50 = "Test" )

    ;this will be false!

  endif

In this example, the register was still blank (or whatever the register was before hitting this code).

To be fair, this is clearly stated in the Uniface manuals...

Only fields can be referenced indirectly; the name reached by the indirect reference cannot be a variable. The following example is incorrect because the indirection refers to a general variable rather than to a field:

$1 = "$99"

@$1 = "This string does not go to $99."

But I still wanted to be able to set registers in an indirect way, so I came up with this alternative...

  putitem/id list,"$50","Test"

  getlistitems/id list

  if ( $50 = "Test" )

    ;this will be true

  endif

This works by populating a list with the register and the value, and then uses getlistitems to populate them.  The "/id" mode copies items from the associative list into one or more fields, or registers in this case.

For example, you could use a simple for loop to clear out all of the dollar registers...

  for count = 1 to 99

    putitem/id list,"$%%count%%%",""

  endfor

  getlistitems/id list

This would set each of the 99 dollar registers to blank.

Summary: Indirection works great for fields, but not for registers - however, you can use getlistitems to achieve the same outcome.

What are handles and should I be using them?

The Uniface manuals describes a handle as...

A handle is a reference to an object, such as a component instance, entity, occurrence, or field. Handles can be used to call operations on the referenced object, or to pass these objects as variables and parameters.

If you're used to pointers, you may at first glance think that these are the same, but they're not.  A pointer contains the address of an item in memory and is therefore fixed, whereas a handle is an abstract reference, which means the address can be changed without breaking the reference.  This makes them very useful.

In Uniface you can have "public" or "partner" handles, which allow you to define which types of operations can access them.  They are also datatypes available for local, component and global variables, depending on the scope required.  I'm not going to discuss either of these points in detail, but I think it's handy to know.

As the description in the manual states, you can create a handle that references most Uniface objects, and there are different methods for creating these handles:  Component instances ($instancehandle), entity collections ($colhandle), entity occurrences ($occhandle), fields ($fieldhandle) and also OCX controls ($ocxhandle).  

I'm going to focus on component instances.  More specifically, I'm going to focus on creating new component instances, using newinstance and handles.  

As you might expect, creating a new instance of a form has a little lead time.  Using a handle doesn't stop this lead time, but what it does do, is mean that it only has to happen once.  This means that using a handle for a single form activation is not going to give you any advantage (unless you just love handles!) but when calling operations on the same form multiple times, handles could give you a performance improvement.

This is something like how you could activate a form...

  activate "TEST_FORM".test_oper("Test")

In fact this does an implicit newinstance as well (if it can't already find an instance with the same name as the form) and so explicitly your code could look like this...

  newinstance "TEST_FORM","TEST_FORM"

  activate "TEST_FORM".test_oper("Test")

If you were to replace this with a handle then you may use something like this...

  newinstance "TEST_FORM",theHandle

  theHandle->test_oper("Test")

Notice that in this case we have used a handle instead of an instance name in the newinstance call, and then we can use this handle in place of the activate command.  The -> is referred to by Uniface as the "dereference" operator, and is processed with a precedence of 2 (with only field indirection being higher).

So let's try these two different ways of activating an operation (in this case a very simple operation that simply returns out immediately).  The newinstance command is done before the loop, and the activate (or equivalent handle call) is done inside the loop, 200,000 times...

• Using activate: 2.56, 2.61, 2.60 (about 2.6 seconds)
• Using a handle: 2.39, 2.35, 2.39 (about 2.4 seconds)

As you can see, using a handle is marginally quicker, although you'd have to be making a lot of calls before you really noticed the difference.  

I thought that this would be even more useful when the handle references a component instance that is running on another server, such as when a form is mapped to run elsewhere, as the I thought the initial creation of the new instance would take longer here.  So I ran the same operation 20,000 times (after mapping the form)...

• Using activate: 13.39, 14.35, 12.99 (about 13.5 seconds)
• Using a handle: 13.56, 13.12, 12.91 (about 13.0 seconds)

Not much difference here either.  Having said that, maybe on a chatty network the difference would be greater.

Please note:  You must return out of the operation that you call, if you exit out then this will destroy the handle and future calls to the operation will fail with a $status of -1.  To clean up a handle you can either set it to 0 or "" (empty string). 


Summary: Handles are abstract references to pretty much any Uniface object.  They can be useful, especially if you want to call the same object multiple times, but they don't seem to have the performance benefits that I was expecting, not when it comes to component instances anyway.

Undocumented feature - error stack

This is something which has previously never been documented by Compuware.  In the Uniface 9.5 manuals it is used in a code example, but isn't explained at all.   We first found it in 2008, when we were on Uniface 9.2.  I've called it an "error stack", because that's the context we use it in, but really it's accessing the process stack, so you can determine where you are within the code at runtime.  And it's as simple as this...

stack = $proccontext("STACK")

I could just leave it there, but that seems a little mean, so I'll continue :)

At this point the "stack" variable is populated with a Uniface list.  Each item in this list contains another list, which contains the following items...

• TYPE - The type of item on the stack ("TRG" for trigger, for example)
• INSNAM - The instance name of the form running (or application shell)
• TRIG - The trigger of the form running ("execute", for example)
• ENTITY - The entity name of the item (if you're in an entity or field trigger)
• FIELD - The field name of the item (if you're in a field trigger)
• MODEL - The model name of the item (if you're in an entity or field trigger)
• MODNAM - The name of the item (the entry or global procedure name, for example)
• LNR - The line number within the item
• LIN - The line of code itself

So you can loop through this list (forwards if you want it like a stack, or backwards if you want it to be more readable) to determine how you managed to end up where you currently are, down to the line number.  This is really useful for outputting when errors occur, especially in global procedures, as you can see what form was running at the time, right back to the application shell.

Thanks to Mark R for telling me about this one!

Summary: It is possible to determine exactly where you are within code at runtime, which is really useful for error messaging.

Performance of string manipulation - part one

One thing that every developer fights with (or should!!) is performance.  It's ok writing an application that works well for one developer sat messing about on a development server that only he is using, but it is very different when it's thousands of users all hitting the same server, under realistic but heavy load.


One particularly costly task is string manipulation.  Building up a string can use a relatively large chunk of memory and take a surprising amount of processor power.  So I decided to perform some performance tests to see how this could be improved.


The first test I did was comparing the use of a local variable against a non-database field.  I did this test by taking the following string...


" ABCDEFGHIJKLMNOPQRSTUVWXYZ 01234567890 abcdefghijklmnopqrstuvwxyz 01234567890"


...and then using putitem/id with a counter to add this 20,000 times, with the following results...

• Non-database field = 02:42.14, 02:44.64, 02:43.44 (almost 3 minutes).
• Local variable = 00:00.22, 00:00.23, 00:00.22 (less than 1 second).
• Component variable = 00:00.22, 00:00.22, 00:00.22 (less than 1 second).
• Global variable = 00:00.22, 00:00.22, 00:00.23 (less than 1 second.

As you can see, when manipulating a string you should never use a field to hold the string.  Having said that, it doesn't seem to make any difference which type of variable you use.  I continued testing the different types of variables with 200,000 and 2,000,000 iterations, without seeing the times deviate from each other.

Summary: Use a variable (any kind of variable) but not a field.