$fieldname return PROCERR[<UPROCERR_FIELD>]

Author: marco.aquino@dedalus.eu (Marco)

Hi,
I found this error that in U8 did not appear.
The value of $fieldname return PROCERR[<UPROCERR_FIELD>] instead of name of field.
This appear when a setocc on other entities is performed.
Then if a new test on it like if (@ $ fieldname! = "") or assignment @$fieldname=$$VAR crashes Uniface.

Example like this

Detail trigger on a field:

call lf_proc
if (@$fieldname="")
   return -1
end if
return 0

 

the entry proc:

entry lf_proc
   setocc "ent",1
   while($status > 0)
      ...something...
   endwhile
end

The $fieldname change value  after a setocc instruction and the uniface crashes on "if" statement or at the end of trigger if I used an assignment.

 

Windows XP or Windows server 2003 R2 32bit
Uniface version 9.4.0.1 R117 or R124 also

 

Marco

 

18 Comments

  1. Quick solution,
    Replace @$fieldname with <$fieldname>, this hard codes the field name in at the time of compilation, and is therefore 'proof' against this issue.

    We have been wholesale replacing $fieldname with <$fieldname> in all the detail etc triggers, and it certainly makes life less fraught.


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  2. Hi marco,

    we encountered similar things when the "active path" is touched in the middle of a proc code.

    Looks like performing entity-based-commands will extinguish the $fieldname pointer

     

    Iain's suggestion using <$fieldname> precompiler constant has a lot of benefits:

    - directly bound during compile (will speed up processing)

    - works on "control" fields as well where $fieldname in not the name of the field activating the DTLF

     


    Author: ulrich-merkel (ulrichmerkel@web.de)
  3. The Iain's suggestion is very powerful, but it solves only a problem on field trigger.

    In my example I show the code to generate error, but in my application the code is in a global proc and is used on many fields and the suggestion doesn't work.

    Marco

     


    Author: Marco (marco.aquino@dedalus.eu)
  4. the 9.4.R123 documentation is not too clear but ....

     

    $fieldname returns:

    • Name of the current field if Field is not specified. If there is no current field (that is, if the last node of the active path is not a field), $fieldname sets $procerror to -1101.
    • Name of the field, if Field is specified and the field is present in the component.

    If an error occurs $procerror contains a negative value that identifies the exact error.

     

    ... may say there is not always a target for $fieldname (put it as a watch in the debugger and see what happens)

    In the old days, it was said there is no $fieldname possible in entity triggers.

     

    And because @$fieldname directly uses the pointer, this is there it may cause the mess.

     

    In your global procs, it may be enough to assign $fieldname to a dummy and check procerror afterwards before you use @$fieldname


    Author: ulrich-merkel (ulrichmerkel@web.de)
  5. If it's in global proc then something like what Uli said would work. v_fieldname = $fieldname call lf_proc if(@v_fieldname="") return -1 endif return 0


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  6. Yes, a global proc may be easier to "correct" the problem.
    In the beginning of code I add a

    v_fieldname = $fieldname

    and after I test the local variabile instead of $fieldname, but it is possible, and this is a real case, that before a global proc I have other code with a setocc instruction inside, for example to control something, that make a $fieldname in error.

     

    Marco


    Author: Marco (marco.aquino@dedalus.eu)
  7. what about the following?

    in each field level trigger, cache $fieldname into v_fieldname (or $fieldname$) immediately

    and use the variable afterwards instead of $fieldname


    Author: ulrich-merkel (ulrichmerkel@web.de)
  8. Yes, this is the workaround but I must check every trigger because I have the common code in global proc and I used it.

    Is not sufficient to save the value of $filedname in a local variable, because I don't know if every trigger that use a global proc has or not code before that causes a $fieldname error. The right way is to pass a global proc a saved value for use it, so I need to change definition of global proc, or use, and then defined in every component, a component variabile to save and use the right value of $fieldname.

    I remind that in the previous version U8 worked fine, it is conceivable a solution by Compuware?

    Marco


    Author: Marco (marco.aquino@dedalus.eu)
  9. If you are changing the occurrence, then the $fieldname value is undefined anyway. Your code is built to USE a bug in Uniface which they have since fixed. Unless you are returning to the 'current' occurrence at part of your setocc operations, you cannot and should not rely on $fieldname being what it was when you left the original occurrence.

    I think we are possibly missing something in that you have not told us what the 'setocc' stuff is doing for you. And/or why it's likely to fire before the global proc.


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  10. Ian, thanks for your answer, but for me this bug fix is a problem.

    I don't know how much code I need to change, we have more than 4000 components potentially affected by the problem.

    Debugging I see the same behavior with U8 and U9, after setocc instruction the value of $fieldname is "PROCERR[<UPROCERR_FIELD>]", but when I back in detail trigger and I do

    @$fieldname = value

    U8 works, U9 crash.

    I tried to return on correct entity by setocc instruction and the $fieldname now is not in error, but the value is the first field of entity and not a field where I do the action.

     

    I think that in trigger field level is correct that value of $fieldname is the field itself always, I'm doing a field action (detail, leave field, etc).

     

    Marco


    Author: Marco (marco.aquino@dedalus.eu)
  11. Hi marco,

    unfortunately $fieldname is not the name of the field hosting the trigger if it is "CONTROL" type.

     


    Author: ulrich-merkel (ulrichmerkel@web.de)
  12. Ok I know, but my field is "database" type and in this case (also in non-database or boilerplate) I think that the value of $fieldname, in trigger code, should be the name of field, because the focus is on the field. For control type the focus is not so.

    Marco

     


    Author: Marco (marco.aquino@dedalus.eu)
  13. But your statement was that this code is not in a field trigger, but in global proc called by the field trigger? Otherwise the fix to replace @$fieldname with <$fieldname> would work.


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  14. I think that the content $fieldname is a volatile/fragile issue and (at best) is valid in non-control fields if nothing touches the active path in between.

    I recommend a $$fieldname variable which is set in each field-related trigger as a quick-fix.

    Better, but much more exhausting is the migration to pass the fieldname as an argument to each global proc.


    Author: ulrich-merkel (ulrichmerkel@web.de)
  15. Ian you are right, my code is in a global proc but call in detail field trigger.

    The right solution is pass parameter with name of field to global proc and use it instead of $fieldname like Ulrich says.

     

    Marco


    Author: Marco (marco.aquino@dedalus.eu)
  16. Sounds good. You can probably do this by exporting the app to XML and using a global find and replace to set all "call GLOBAL_PROC" to "call GLOBAL_PROC("<$fieldname>")"


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  17. another quick-fix modification to have the changes in a single place:

    "call GLOBAL_PROC" is cloned into GLOBAL_PROC1 and uses the fieldname parameter now.

    the existing GLOBAL_PROC just calls the new one with $fieldname as the parameter (assuming $fieldname is correct when calling)
    "call GLOBAL_PROC1($fieldname)"

    Brings down the workload, but has some assumptions about calling context.


    Author: ulrich-merkel (ulrichmerkel@web.de)
  18. I like both solutions.

    I'll be consider what is the best for me.

    Marco


    Author: Marco (marco.aquino@dedalus.eu)