Tag Archives: Migration

Triggers’ default behavior in Uniface 10

With the release of patch F205 for Uniface 10.2.02,  the Uniface 10 compiler has changed to ensure compatibility with Uniface 9 for triggers having default behavior. This blog explains when and how Uniface handles ‘empty’ triggers and invokes default behavior.

A small subset of the triggers in the Uniface model (*) falls back on default behavior if these triggers do not contain executable code. A typical example is the On Error trigger for a field or entity. If you do not define the trigger, the Uniface run time engine will still invoke default handling for error situations. If the trigger has been defined with executable code, only that code is executed, and the default behavior is suppressed.

(*) see the Uniface documentation, section “Triggers with Default Behavior” for the complete list of applicable triggers.

When does a trigger *not* have executable code and revert to default behavior?

In Uniface 10, default behavior is invoked if any of the following conditions is true:

  • the trigger is not declared at all
  • the trigger declaration contains no executable code
  • the trigger declaration only contains one or more pre-compiler directives that do not result in executable code
  • the trigger is undeclared.

Some examples:

Uniface Trigger

Uniface Trigger

Uniface Trigger

Uniface Trigger

What is the impact of the Uniface Inheritance model, how to restore default behavior?

Behavior defined in code containers is inherited at ‘lower’ or ‘derived’ levels. Examples:

  • a modeled entity subtype and its fields inherit from a supertype and its fields
  • a component can inherit from a modeled component (called component template in Uniface 9)
  • an entity or a field in a component’s data structure inherits from the modeled entity or field.

Inheritance can take place over multiple levels, but that’s beyond the scope of this blog.

In Uniface 10, inheritance of code in containers is module-based. Code is contained in explicitly-declared triggers, entries and operations.  If a trigger is declared again on the inheriting level, that definition takes preference and replaces the definition that was inherited from the higher level.

To suppress an inherited trigger in Uniface 10, use any of the options described above: declare an empty trigger, declare a trigger with comment only, or undeclare the trigger on the lower level. An ‘empty’ trigger or undeclared trigger will fall back on default behavior if that is applicable for that trigger.

The following table shows some examples:

Modeled Field trigger error Component field trigger error Result
not declared not declared Default error handling
trigger error
end
not declared Default error handling
trigger error
if ($error = 0105)
… some code
return -1
endif
not declared User defined error handling
trigger error
if ($error = 0105)
… some code
return -1
endif
trigger error
end
Default error handling
trigger error
if ($error = 0105)
… some code
return -1
endif
undeclare trigger error
end
Default error handling

What has changed since patch F205?

With the solution for Issue # 31689 in patch F205 (Uniface 10.2.02), explicitly-declared triggers that are effectively empty now fall back on default behavior, if that is applicable for that trigger.

Before this patch, an explicitly declared trigger in Uniface 10 without executable code or with comment only would not only break inheritance, but also suppress its default behavior. Prior to F205, the only way to ensure that default behavior was invoked was to not declare the trigger or to undeclare the trigger. In case of inheritance of a trigger from a higher level, the only way to restore default behavior on the lower level was to undeclare the trigger.

What has changed since patch F206?

In patch F206 the automatic migration logic in Uniface 10 was changed to benefit from the modifications in patch F205.

Before patch F206, the migration would attempt to assess whether a trigger container coming from Uniface 9 with potential default behavior contained comment or entry declarations only. If so, the trigger would be commented out or undeclared. This approach was not watertight and had a few disadvantages, like adding code during the migration (‘code pollution’) and causing additional compiler warnings compared to Uniface 9.

When migrating a Uniface 9.6 or 9.7 export file into Uniface 10 after installing patch F206, all triggers, including those with potential default behavior, are migrated ‘as is’.

Patch F205 is compatible with code migrated into a Uniface 10 using a patch prior to F206, i.e. there is no need to redo the migration. However, if you want to benefit from the changes in the migration, you should migrate after installing patch F206 or higher.

Heading towards Uniface 10.3

Since the release of  Uniface 10.2 the topic of custom utilities on the Uniface repository has come up several times during conversations with customers, at user events and in the forums. The plan is that we address at least part of these requirements (making umeta.xml available) in 10.3.

Migrating to Uniface 10
Uniface Entity Editor

Why wait for 10.3? The migration from 9 or 10.2 to 10.3 will require a full migration, an xml export and import. This is something we don’t do in patches or service packs. The reason for the migration is that we are working towards locking the repository to offer a stable platform for customers. By stable I mean one where, for the foreseeable future, we will not require customers to undertake a full migration. We have planned changes and are validating them to make sure we can implement the functionality we would like to deliver. For Work Area Support we need to make sure that, as much as possible, merging is possible. For global objects (USOURCE) we are splitting it in to multiple tables to more closely reflect the data they hold.

With the repository being updated there are some areas in the development environment that also need some attention, we need to ensure they continue to work:

  • The compiler
  • Export/Import
  • The hybrid components
  • xml
  • Migration
  • Create Table Utility (for repository and user tables)

Whilst on the subject of the “Create Table Utility”… We have been thinking how it might fit into the IDE, should it have its own workbench or should we achieve the functionality in another way? There are currently two implementations we are looking at. Firstly, from the command line. This option is how, in the future we will be supplying the scripts for the repository. Getting Uniface to generate the scripts, rather than a static list being supplied with the installation, will mean more deployment options – it will use driver options in the ASN to generate the correct scripts for your environment.

Uniface Scripts
*Example only

Secondly, we are looking at adding a create table menu option to the project editor. With this method it would be possible to collect all the tables you need generating into a project and asking Uniface to generate the scripts for you.

Uniface Table Menu

Uniface 10: What’s happened since the release?

Back in September 2016 we had quite a major event, Uniface 10 was released with the ability to develop and maintain all forms of Uniface applications – Client Server, Web and batch.

Uniface 10

Since the release, and based on lots of feedback from the early adopters, we have continued to actively enhance the IDE with constant incremental improvements. In this blog post, I would like to share with you what these improvements are as well as what we have planned for the near future.

To start, it is probably a good idea to give some high-level topics we have been concentrating on.

Migration

This topic has probably been our primary focus during the continuous updating of v10. We have always had a migration path between Uniface versions automating any updates needed. In version 10 we continue with this concept and as information becomes available, from customers and our own experiences, the migration utilities have been updated to further improve the experience.

Uniface 10: Code migrated from 9 to 10
Uniface 10: Code migrated from 9 to 10
Usability and bug fixing

Performance in large repositories has proven to be an area where we have needed to pay attention and has generated some lively discussions on uniface.info. Although this is an ongoing theme we have already made significant enhancements. The dropdown browse dialogs for the Development Objects (cpt:, ent:, libinc:, etc) will load the information and format the data with considerably less of a delay. Incremental rendering has also been added so that the list becomes available and usable even while extra rows continue to be added. The same techniques and improvements will also be added to the resource browsers in the coming patches.

Uniface 10: Cascading brows dialogs
Uniface 10: Cascading browse dialogs
Embedding the GUI screen painter

Client server development is another area we are enhancing. The first enhancement we are planning and currently working on is embedding the form painter directly into the v10 IDE.

Uniface 10: Embedded form painter taken from a developer's PC
Uniface 10: Embedded form painter taken from a developer’s PC
Runtime enhancements

It is now possible to specify what trigger, accept or quit, will be called when an auto close popup loses focus.

The ability to undeclare a trigger, operation or local proc. This will allow model or previously defined scripts to be excluded from the compile effectively allowing default functionality for a trigger to be re-established.

The ability to call up to a higher-level trigger has been added, this allows such actions as explicitly calling the entity level Detail trigger from the field level detail trigger.

Uniface 10: New popup options
Uniface 10: New popup options

As you can see, we’ve been very busy, and there is a lot more to come.

End of support for Uniface version 8

We would like to remind that you that as of December 2009, official product support for Uniface 8 will end.

This effectively means that our Development Labs in Amsterdam will no longer create bug-fixes, new platform currency and/or additional functionality for the entire Uniface version 8 code line.

We will continue to answer customers’ questions at our helpdesks and even provide customers with workarounds and bug-fixes for already known issues in the Uniface 8 product.

If there are any questions, please contact your local representative or send a message to askuniface@compuware.com

 

For more information, please review the following document (PDF):