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.

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.

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>")"

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

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.

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.

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

Hi marco,

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

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

I like both solutions.

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

Marco

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

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

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

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

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

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

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

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.