I think it's fair to say that the organisations that'll come across this issue are long time Uniface customers. With that in mind, maybe the convert process should 'automatically' insert either a pragma something or a new precompiler directive (as pr Iain's suggestion (thumbs up - twice!!) in the process when it hits a single 'commented' out trigger. This way we get to retain our current functionality, the code should execute just as it does today in 9.6. Then, if/when we need to, we can remove the precompile / pragma statement and move forward with the new, improved way... Knut

Any chance we could get an update / direction statement on this issue?? Knut

We are working very hard on this in the Lab. We are looking on what to do in the migration process. Also looking at the situation where you have some code in the Model, but want to have the default behavior in a specific component. Some very fierce discussions going on while I am typing this.

Oh how I would like to be a fly on them their walls in Amsterday atm..

Another "issue" with inheritance Say, you have in UCGROUP defined the READ-trigger (as part/fragment of the entity scripts) Now you want to insert this script fragment into the component and modify it a little bit. How to do so? Don't answwer one have to open the model->entity->script  and copy&paste the fragments In good old UF9, you see the model defined trigger. On start-modify, Uniface copy this one into the UXGROUP. And if you double click the trigger you got the original back The behaviour is very important too us as we insert e.g a DEBUG temporary in this triggers. Are there any plans to implemant things like this in UF 10? Regards Ingo

In essence, you've just stated that we'll (and that's the collective we - as in all Uniface customers world wide) have to go through every component, check every single trigger in every single field, entity and component to see if we've overridden / commented out the default model/template behaviour? Through thousands of screens, through code that hasn't been (possibly (even most likely)) been touched for years.... and then find a way to 'wrap' those non-wanted model snippets.... I need a large cup of tea...

Knut said In essence, you've just stated that we'll (and that's the collective we - as in all Uniface customers world wide) have to go through every component, check every single trigger in every single field, entity and component to see if we've overridden / commented out the default model/template behaviour? Through thousands of screens, through code that hasn't been (possibly (even most likely)) been touched for years.... and then find a way to 'wrap' those non-wanted model snippets.... I need a large cup of tea...  

No, as Daniel said above, we're looking into these.  I said last week, we want to automate these use cases as much as we can, and we want feedback on them so we can work on them. We expect to deliver frequent updates to the migration utility to provide solutions. 

Knut ... better a dark, dark coffee 

Coffee gets me going, tea to calm me down

Perhaps a precompiler directive for where there are currently LPMX entries disinherited so that they all REMAIN disinherited after migration, and the developer can then removed this directive from the relevant programs where they wish any new code to be properly inherited? 

Hi Knut, This change in behavior is described in "What's New in Uniface 10" > "Uniface 10: Changes in ProcScript Inheritance":

Consequences

Changing the way ProcScript modules are inherited makes ProcScript inheritance consistent and predictable, but it may affect your migrated application:

• Entries migrated from standard triggers and Local Proc Modules may now be inherited. If not overlaid by a locally-defined entry, these entries are added to the locally define entries. If the entries are never called, no functional changes will occur, but they may result in additional compilation warnings and errors errors that need to be fixed.
• Inherited entries may now overlay entries that were not overlaid in Uniface 9, or were overlaid by another entry. In this case, the application behavior may change, and you will have to fix it. The Uniface 9 compiler already warns of potential inheritance differences, so you can refactor your code in Uniface 9 before migrating it to Uniface 10.

For more information, see Entries. If I understood it correctly then the lab is currently looking into possibilities, how the migration utility of Uniface 10 could support you here. Henk has probably more info about this. One way to overcome this issue could be by creating a small migration routine that would add defines around the code in the LPME and LPMF triggers of the modeled entities (e.g. #ifundefined LPME_IGNORE). In case you also have local Proc modules in other triggers than the LPME and LPMF then this would make things a bit more tricky. After this done you have add the specific defines to the components where the LPME/LPMF trigger is commented out. Okay, in order for this to work correctly you would need to create unique defines for each LPME/LPMF trigger (adding the specific entity and model name, and for the field triggers the field name). If you're interested then drop me an email and I could share a prototype that I've made for the LPME triggers. Hope this helps. Kind regards, Daniel