To answer your first question first: Uniface 9 actually does have several types of proc-containers. There are the so called Standard Triggers (read, write, etc), which indeed have a 1:1 mapping between container and trigger, and there are the Extended Triggers trigger and Operation trigger. These triggers are actually not triggers in a way that they can be fired (although the name suggests otherwise); they are merely containers that contain triggers/operations. The fact that we has 2 types of containers, both with their own specific way of inheritance, is the reaons to change this in Uniface 10 into 1 type of container. So, in Uniface 10 we only have 1 type of code-container. In this container you define the local variations of any trigger, operation, or entry. The compiler, however, also includes the proc of the object form which component inherits. So, although you do not see it in the code editor of the IDE, there is still inheritance. Now, this is a good moment to point out the Post Compile Proc Module listing, This is the thing that you see at right of the code editor in the Write Script worksheet of the Component Editor. After compilation of the component, this view shows the list of proc modules the component has at run-time including any inherited, included, or generated proc modules. So this list is way more complete that whet we always suggested in V9. The only thing we do not do (yet), is show the code. But the need for that is also less important, because you simply double click one of the itens in this list and navigate to the source(the location where the code module is actually declared). So inheritance in Uniface 10 is not different from Uniface 9; it is only the way you specify proc modules. After compilation, everything is the same. Hope this helps a bit - Gerton

Hi Gerton Okay, after compilation it may be the same. But for me/us as a developer of applications, it is a big diffence! How can I see on editing the inherited code?   -> Looking into the listing is far too late! How can I insert the code defined in model (for modify just a little bit) into component?   -> Every time Cut&Paste from another editor window to the place in question is not a solution! So bring back the old behaviour:    I see the inherit code    I can modify it easly Long time ago, UnifAce was THE development tool Now UnifAce converges to the bad attributes of all other tools and loosing it's benifits Regards Ingo

Hi Ingo, we realize it is different and, indeed, it is powerful to see the inherited code. Unfortunately, it only worked for standard triggers, it never worked for extended triggers and operations. So Uniface 9 was not consistent and that is a problem. Additionally, the post compile list also works for included code, something we never had in V9. That being said, we still have a bunch of enhancements planned in this area:

• we will introduce more navigation
  • where your can always jump to the object from which a component inherits using a single click
  • where you can navigate directly to an include proc from the #include statement
  • where you directly navigate to the entity from any entity reference in code, etc.
• we will introduce a menu option to directly insert inherited code into the local editor; no copy-paste needed
• we might introduce an advanced tool-tip, including syntax highlighting and copy/paste capabilities, showing code that is being inherited from the entity
• we might introduce an advanced tool-tip, including syntax highlighting and copy/paste capabilities, showing code that is including while hovering an #include statement
• continues background compilation so this post compile proc module list is always up to date
• ...

 So, much more to come. Gerton

Okay, let's see But if you will "enhance" UnifAce, what about a true inheritance? i.a, have the keyword/function $super to call triggers e.g. TRIGGER formatToDisplay   $super()->formatToDispay() END So one can call the code defined in the "upper" object. BTW 1: One drawback of this all in one code is, that on have to type much more text :-( BTW 2: Will there be an easy search&replace of code that belongs only to one trigger? Ingo

$super()->formatToDispay() is a good idea. We also though about that feature. The reason why we did not get to it (yet?) is the additional complexity involved in the implementation. For $super to work, the code that $super refers to has to be included by the compiler as well, and that requires a serious rewrite of parts of the compiler. A risky effort. I'll keep this in mind. Thanks - Gerton

Gerton Leijdekker said $super()->formatToDispay() is a good idea. We also though about that feature. The reason why we did not get to it (yet?) is the additional complexity involved in the implementation. For $super to work, the code that $super refers to has to be included by the compiler as well, and that requires a serious rewrite of parts of the compiler. A risky effort. I'll keep this in mind.

Hi Gerton If you on the way to "rewrite" the compiler, do consider of  "mangeld object names" So in the future*) it will be possible to overload functions Ingo *) UF 10.2/10.3