Skip to main content

Uniface 9: Form based on Formtemplate

  • November 19, 2018
  • 3 replies
  • 0 views
Jan Cees Boogaard

Form based on Formtemplate

Author: juerg.fross@teamspirit.ch (jfro)

Hello

Wie are working with Uniface 9.04.01.02 and just encountered a in my opinion strange behaviour. I would like to know if you think this is normal or not.

We have different forms basing on a form template. In this form template we have in the <operation>-trigger an include-proc "#include TS_STD_LIB:IP_STD_F_OPER".

  • In one of these forms we wanted to disable this standard include-procs. So we just commented the proc wih ;
    After compiling it was "of course" still commented. During debugging we discovered that Uniface still uses the include-Proc - Code from the form-template. In the listing we could see that Uniface loaded the commented include-Proc from the template.
    So what we see in the operation-trigger doesn't correspond to what uniface really does.
  • We made another try and deleted the include-Proc statement in the operations-trigger and wrote "return (-1)". After compiling we still had our "return(-1)" - but again in running the form Uniface activated the "old" include-Proc from the template.

Is this a bug? Or do I simply not understand how Uniface works?

Thanks for your comments!

Jürg

 

 

 

 

 

    3 replies

    Jan Cees Boogaard

    Form based on Formtemplate

    Author: juerg.fross@teamspirit.ch (jfro)

    Hello

    Wie are working with Uniface 9.04.01.02 and just encountered a in my opinion strange behaviour. I would like to know if you think this is normal or not.

    We have different forms basing on a form template. In this form template we have in the <operation>-trigger an include-proc "#include TS_STD_LIB:IP_STD_F_OPER".

    • In one of these forms we wanted to disable this standard include-procs. So we just commented the proc wih ;
      After compiling it was "of course" still commented. During debugging we discovered that Uniface still uses the include-Proc - Code from the form-template. In the listing we could see that Uniface loaded the commented include-Proc from the template.
      So what we see in the operation-trigger doesn't correspond to what uniface really does.
    • We made another try and deleted the include-Proc statement in the operations-trigger and wrote "return (-1)". After compiling we still had our "return(-1)" - but again in running the form Uniface activated the "old" include-Proc from the template.

    Is this a bug? Or do I simply not understand how Uniface works?

    Thanks for your comments!

    Jürg

     

     

     

     

     

    addition ...

    this behaviour was introduced for passing newly defined operations you place in the component template to the "subscribing" components.


    Author: ulrich-merkel (ulrichmerkel@web.de)
    Jan Cees Boogaard

    Form based on Formtemplate

    Author: juerg.fross@teamspirit.ch (jfro)

    Hello

    Wie are working with Uniface 9.04.01.02 and just encountered a in my opinion strange behaviour. I would like to know if you think this is normal or not.

    We have different forms basing on a form template. In this form template we have in the <operation>-trigger an include-proc "#include TS_STD_LIB:IP_STD_F_OPER".

    • In one of these forms we wanted to disable this standard include-procs. So we just commented the proc wih ;
      After compiling it was "of course" still commented. During debugging we discovered that Uniface still uses the include-Proc - Code from the form-template. In the listing we could see that Uniface loaded the commented include-Proc from the template.
      So what we see in the operation-trigger doesn't correspond to what uniface really does.
    • We made another try and deleted the include-Proc statement in the operations-trigger and wrote "return (-1)". After compiling we still had our "return(-1)" - but again in running the form Uniface activated the "old" include-Proc from the template.

    Is this a bug? Or do I simply not understand how Uniface works?

    Thanks for your comments!

    Jürg

     

     

     

     

     

    Hello Uli

    As I thought in a way... A behaviour I didn't know about.

    Thanks a lot for the very fast competent answer!

    Jürg

     


    Author: jfro (juerg.fross@teamspirit.ch)
    Jan Cees Boogaard

    Form based on Formtemplate

    Author: juerg.fross@teamspirit.ch (jfro)

    Hello

    Wie are working with Uniface 9.04.01.02 and just encountered a in my opinion strange behaviour. I would like to know if you think this is normal or not.

    We have different forms basing on a form template. In this form template we have in the <operation>-trigger an include-proc "#include TS_STD_LIB:IP_STD_F_OPER".

    • In one of these forms we wanted to disable this standard include-procs. So we just commented the proc wih ;
      After compiling it was "of course" still commented. During debugging we discovered that Uniface still uses the include-Proc - Code from the form-template. In the listing we could see that Uniface loaded the commented include-Proc from the template.
      So what we see in the operation-trigger doesn't correspond to what uniface really does.
    • We made another try and deleted the include-Proc statement in the operations-trigger and wrote "return (-1)". After compiling we still had our "return(-1)" - but again in running the form Uniface activated the "old" include-Proc from the template.

    Is this a bug? Or do I simply not understand how Uniface works?

    Thanks for your comments!

    Jürg

     

     

     

     

     

    Hi Jürg,

    OPERATIONS are a different issue if it comes to inheritance.

    Placing some code in the local operation trigger does NOT wipe out inheritance as a normal entry will do.

    The only way to inactivate operations is define this operation with a single RETURN.

    The compiler will tell you something about OVERWRITE.

    Uli

    P.S: One upon a time in the good old days of documenation there was a not about this when they introduced component templates.

    If you have nothing better to do, try to find it in the current CHM (or ask your friendly local CPWR/Uniface contact)


    Author: ulrich-merkel (ulrichmerkel@web.de)

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement