This is an interesting code practice although it assumes the developer has knowledge about the order in which the version 9 IDF compiles the Proc containers / triggers of entities and fields. We presume that the purpose of this construction is to protect specific pieces of code from being overridden and we understand that the way in which version 10 deals with code inheritance may be a cause for concern for some users. It is noteworthy, though, that this code practice is not failsafe. For example, in version 9, entries in a “secure code” container of an entity would be overridden by other entries found later in the compilation sequence. Examples of such entries, in v9, overriding the secure code are ones defined in other modeled entities, or their fields, painted lower in the structure, or by any entries in a field or entity only defined on the component. The ambiguity of how version 9 deals with container inheritance, the order of inheritance handling, and duplicate module overlay is one of the reasons why version 10 introduced the single Code Container per development object, with inheritance only at module level. To make customers aware of situations where version 10 deals differently with duplicate module overlay, there is already the option of compiling their version 9 components with the idf.exe that is in the version 10 bin directory. The compiler issues a special compilation warning for such situations. We are thinking of ways to help customers who use such practices as you describe, so they can migrate to version 10 without too big an effort. At the same time, we’re thinking of ways to help them protect specific pieces of Proc code in a predictable way. We will now be looking at this topic as two items:

• How can we enable the development community to move to version 10 with the minimum of required effort.
• The idea of being able to protect code against being overridden is a nice one and we are looking at what possibilities there are within the language to help enforce it.

The thinking is still early so I have nothing to share as yet however there are some interesting ideas.

Hi Frank, thank you for your kind reply. We had to find some way if some utilities have been provided as modeled entities which have some must-not-touch as well as you-can-customise-it procs. We even have predefined pullable "UserExits" to provide hooks where the using coder could start further processing. Sure it's not failsafe, but we exploited that when a modeled field is not painted, its trigger-codes are compiled, but can not be modified locally. There were also plans using "dITo Uniface Reflection" to include all these codeblocks at the very end of the form; but this way we would have lost the benefit of coding with <$entname>.   Other languages have in their toolbox a some "final" definition or an "@override" annotation to cope with this situation. so if the compiler detects an overwrite without correct annotation, it will raise an error. Or really going back a couple of uniface versions where duplicate entrynames were not allowed? Greetings from Frankfurt/Germany, Uli