drama because the “one” of UCFIELD has changed

in the repository, we had a small change recently with buggy side-effects; implementation needs improvement.

Not too many have noticed that an important change in the DICT repository has been done recently.

UCFIELD is no longer related down to UCTABLE, but to each UCGROUP instead.
After the change in relationship, the IDF has to take care that when entering a field, this has to be duplicated to each entity of the table.
Same goes if you change the proc code for a field. In the past, there was only one code in all subentities, and now???

What came naturally before causes now some problems:

In the past when you added a field in the datamodel, it was visible in all subentities.
In the past when you change proc code in a field in the datamodel, it was visible in all subentities.

These bugs appear in the wishlist:

uniface.communityzero.com/content/lists Duplication of field duplicate component triggers

uniface.communityzero.com/content/lists Component subtype triggers in field templates

uniface.communityzero.com/content/lists Update of field labels in component subtypes.

I think CPWR should fix these issues as BUGS, so we do not have to waste the limited wish resources on these matters.
Success, Uli

0 thoughts on “drama because the “one” of UCFIELD has changed”

  1. But Uli, the point IS that you get different code in all the sub-entities.
    These are component subtypes. I want different code in my forms from my services and from my USPs.
    We have been waiting AGEs for uniface to bring out the idea of different inheritable code for different tiers in the n-tier environment.
    The issue is, that you now have to hand craft this code every time you use the same class of field. (So, if DETAIL on a date field in a form brings up a ‘calendar’ form for picking a date, you have to cut and paste that code into the form subtype every time you create a date field).

    All of the wishes above, (which are all mine) are to improve the RAD nature of uniface by extending the idea of separate jobs for separate component types further ‘back’ in the repository (i.e. to field templates rather than just fields).
    I’ve never had a new field not show up in a sub-type. And the component subtypes do inherit the code from the supertype.
    They just don’t inherit labels – Bottom wish
    And there’s no way of defaulting in component level behavioural changes – top two wishes.



  2. Hi Iain, a very good argumentation why shifting the one entity makes sense. The problem is that this shift requires duplications in other areas and, as you can see above is very buggy right now. there are better ways to have subtype aware field triggers even in the traditional single-best position of UCFIELD: #if <$entname> == <$tablename>_SVC ….. #endif

Leave a Reply