Blog

Global Objects There are many types of Global Objects, like Messages, Global Procs and Keyboard Translation Tables, to name a few. The Uniface 9 IDF and the Uniface 10 IDE provide editors to maintain the definitions of those objects. You could consider those as the definition-time source objects. Successful compilation of those source objects results in compiled objects, their run-time counterparts. The compiled objects are static objects. User applications can use them, but they have no way of changing them. To change them, you must use the editors in the Uniface development environment (the version 9 IDF or the version 10 IDE) to change their source objects, then compile those and make the resulting compiled objects available to the application.

Counter – the oddball

There is one particular type of Global Object that is different from the others: the Counter. Contrary to other Global Objects, Counters are not static run-time objects. Any application can change them through ProcScript. The numset statement creates a counter or re-initializes its value, and the numgen statement increases a counter’s value. Considering this, you may even consider Counters as run-time data rather than run-time objects. To maintain Counters, Uniface 9 offers the Define Counter dialog. This dialog gives the impression that, like for other Global Objects, it maintains source objects. However, it does not. In fact, there are no source objects for Counters. They only exist as run-time objects, in UOBJ.TEXT. The Define Counter dialog acts directly on those run-time objects. If your application uses Counters, be aware of these aspects, and apply extra care when deploying UOBJ.TEXT. Also, users of the Define Counter dialog might just accidentally change the value of a Counter that is being used by an application.

Migrating Counters to Uniface 10

Uniface 10 is straightforward: it simply regards Counters as user data. The one and only way to change them is through the ProcScript instructions that are intended for just that purpose: numset and numgen. There is no dialog that can be used to adjust Counter values. If you already initialize and maintain your application’s Counters purely by means of ProcScript logic, there is no extra effort involved for the migration of Counters to version 10. This logic will continue to work as it did in version 9. If, on the other hand, you use the IDF’s Define Counter dialog to initialize and maintain your application’s Counters, you will need to act. To achieve the same functionality in version 10, you must implement that logic yourself, using the available ProcScript instructions. Also, you will need to apply the same care as you did in version 9, to make sure that UOBJ.TEXT is properly distributed and/or installed. This example auto-increments a counter. If it does not exist yet, it creates it and gives it an initial value:   ; Auto-increment counter numgen "MYCOUNTER", 1, "MYLIB" if ($status == <UPROCERR_COUNTER>)     ; Counter does not exist.     ; Create it and give it an initial value of 1001.     numset "MYCOUNTER", 1001, "MYLIB"     if ($status < 0)       message "Error generating sequence number."       rollback "$UUU"       done     else       SEQNO = 1001       commit "$UUU"     endif else SEQNO = $result commit "$UUU" endif   Blog: Frank Doodeman Frank is a Software Architect at Uniface.

5 Comments

  1. There is still the question why the Counter Maintenence Dialog is NOT provided by Uniface BV, but each customers should implement his own one. Looks like once again we get only a fraction of the U9 productivity.
  2. It could be an optional source to be imported and used under customer responsibility (UMISC directory). Regards
  3. The counter maintenance form is discontinued in the IDE because it does not belong there, counters are run-time (user) data not development data. We also believe that not many applications are still making use of this form or Uniface counters in general. For applications that still use counters the blog gives a path to move forward if not already implemented like this.
  4. When I started to work with Uniface (5.1), I used counters. For only one month. It is impractical as it straddles object data and application data. Some commit issues as well. We quickly moved to a self-made number generator and maintenance form.
  5. Counters as the concept Uniface defines are impractical as they ARE runtime objects maintained in the UOBJ and so are reliant on having a specific deployment arrangement with a shared UOBJ. However counters as they are more generally defined are essential parts of everyday operations for most of us users in the form of technical keys. Perhaps the time has come for Uniface to reconceptualize its idea of what they are:

     - Give them a Development environment object so that we can define name, start point, increment, etc. at the model or library level [Edit: better yet at the table level]

     - Modify the database drivers to include the means to generate a "sequence" in whatever database we are running against similar to the table creation scripts (for deployment and if it doesnt already exist, at runtime).

     - Provide commands so that we can easily generate the next key out of the database (assuming that DB supports sequences in some form) at run time eg. $nextcounter / $currcounter / $counterexists / $counterproperties.

    Migration of existing counters to the new system is not an insurmountable problem but would require some additional thought and I would imagine not an issue for most customers who probably dont use them. Backwards compatibility could even be provided with all of the same functionality using some form of text driver implementation to maintain the UOBJ functionality that could also be used to implement counters in a "counter table" such as the previous comment I think was describing. [Edit: added to last paragraph].