Hi Henk, as the wold has changed, QA departments nowadays demand "zero warning compiles". It's just to draw your focus that default trigger texts once delivered by uniface are causing now warnings etc. in your current migration process. It's just to give you examples what may be hidden in the codebases of long years uniface customers. In the current situation, my suggestion would be

trigger error ; if it's really needed by the compiler, some dummy code like $1 = $1 end undeclare trigger error

Uli, Thanks for the feedback. Your suggestion is one of many we are considering and would help to get closer to “zero warning compiles”, but I'd prefer a solution that does not require the undeclare statement in an attempt to not pollute the code (this is purely my personal opinion - i.e. not necessarily on behalf of the Lab on all accounts) Uniface has been pretty successful in providing an upward compatible migration to newer versions since the early days of Uniface 3. In recent customer application migrations, we have even seen code that stems from the Uniface 5 era (early 90's). But sometimes migration has a price tag, e.g. because the compiler's checks are more strict in order to enable new features in an unambiguous way. We'll keep the community posted on how we deal with this topic. - Henk

Hi Uli,   We are very much aware of this symptom and are looking into optimization of the migration of such commented out triggers. It's a long lecture to explain what's going on here, but some remarks:

• it's not reported as a compiler error, but a warning (which in your example is reported for the On Error trigger, hence the confusion?)
• commenting out a trigger is an often used 'trick' to break trigger inheritance in Uniface 9 (and older). Such a commented out trigger will still have default behavior - if applicable - in Uniface 9. In Uniface 10 that 'trick' no longer works, and we introduced the undeclare trigger XXX statement to break inheritance without loosing default behavior. See the blog How to restore default behavior by Dennis Vorst for an explanation. A declared trigger in Uniface 10 with just comment, spaces, tabs, CRs or entry definitions to break inheritance has a side effect that may impact application compatibility: it also suppresses default behavior for certain events/triggers:
  • Component
    • execute → edit
    • print → print/ask
    • menu → call up to menu trigger of Application Shell
    • pull-down → call up to pull-down trigger of Application Shell
    • receive-message (Async Interrupt in UF0) → call up to receive-message trigger of Application Shell
  • Entity
    • error → some component specific entity-level error reporting
    • add/insert occurrence → creocc
    • menu → call up to menu trigger of Component
  • Field
    • error → some component specific field-level error reporting
    • menu → call up to menu trigger of Entity
    • help → call up to help trigger of Entity
    • detail → call up to detail trigger of Entity
• To maintain the 'old fashioned' way of breaking inheritance, the migration utility inserts an 'undeclare trigger XXX' statement if a trigger on potentially inheriting level contains nothing but comment, spaces, tabs, CRs or entry definitions. The current implementation of the migration utility treats development objects (components, entities, forms) 'in isolation' and does not try to find out whether an object on a potentially inheriting level (e.g. an entity or field painted on a form) has an inheritance relation with a modeled counterpart; this implementation is partially for performance reasons, and in part because it is unknown whether the modeled definitions are present at all at the time of migration (they may be imported at a later stage). Admittedly, that's not an ideal situation, because the insertion of this statement may cause dozens (to hundreds or thousands) new compiler warnings in Uniface 10; often meaningless. Again, we're looking into optimizing this without compromising the performance of the migration too much.