U10201f114 wrong migration of standard U7 error trigger | Uniface 10 Enterprise Edition | Forum

Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

—  Results per page  —








— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters
For a group of consecutive words like 'end of support' use Match phrase

sp_Feed Topic RSS sp_TopicIcon
U10201f114 wrong migration of standard U7 error trigger
18 Apr 2017
7:18 am
Avatar
ulrich-merkel
Frankfurt/Germany
Member
Forum Posts: 1672
Member Since:
01 Oct 2012
sp_UserOfflineSmall Offline

in U7, the fields error trigger is defaulted to:

; Include an “else” block like the one shown below at the end of any
; Proc written in this trigger.
; . . .
; else
;    message $text(“%%$error”)
;    return (-1)
; endif

 the u1002f114 migration returns an error:

(4\ERROR)  warning:   1000 – Ignoring undeclare; trigger ERROR has not been declared yet.

because this comment-only trigger is converted to:

undeclare trigger error

; Include an “else” block like the one shown below at the end of any
; Proc written in this trigger.
; . . .
; else
;    message $text(“%%$error”)
;    return (-1)
; endif
; end

18 Apr 2017
11:24 am
Avatar
Henk van der Veer
Member
Forum Posts: 52
Member Since:
01 Oct 2012
sp_UserOfflineSmall Offline

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.

18 Apr 2017
1:54 pm
Avatar
ulrich-merkel
Frankfurt/Germany
Member
Forum Posts: 1672
Member Since:
01 Oct 2012
sp_UserOfflineSmall Offline

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

18 Apr 2017
4:54 pm
Avatar
Henk van der Veer
Member
Forum Posts: 52
Member Since:
01 Oct 2012
sp_UserOfflineSmall Offline

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

Forum Timezone: Europe/Amsterdam

Most Users Ever Online: 131

Currently Online: foster06, C.Ferriday
15 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

ulrich-merkel: 1672

Iain Sharp: 581

Theo Neeskens: 326

rogerw: 212

gianni: 208

lalitpct: 194

istiller: 175

-GHAN-: 171

sochaz: 165

Knut: 157

Member Stats:

Guest Posters: 3

Members: 3120

Moderators: 0

Admins: 8

Forum Stats:

Groups: 1

Forums: 62

Topics: 1898

Posts: 8225

Newest Members:

francesco.corbetta@renatocorti.it, fcorbetta, Dorthyokproruh, j609803, CurtisBog, AdminGiftCardRafflecer, mark.dobbs@tribalgroup.com, JacksonKeemssed, bpotiron, Lewpy

Administrators: admin: 23, Adrian Gosbell: 259, diseli: 696, Bob Maier: 2, Nico Peereboom: 54, Michael Rabone: 4, richiet: 406, JanCees: 23