0129 with the chance of a label instead of the fieldname

But you could just define the field as

[0129] Feld %%$componentname%%%-%%$fieldname%%%-%%$entname%%% ist Pflichtfeld!

and then you don't need the LPMX.

Hi Iain,

it is just a demonstration that one can use self-written functions in error messages.

In this case ret_fieldlabel

This function will deliver the text of the fieldlabel  with the next iteration of this study.
As we now, this is a not too easy quest to get the thing the user has in front of the field.

If you or others have some time to find a way to make this happen, feel free to join the band.

$item("TEXT",$labelproperties($fieldname))

thanks for the tip, it even returns the "default" of the field.

Think when I experimented with $labelproperties, this was not the case

So we have our message as:

[0129] Field %%$item("TEXT",$labelproperties($fieldname))%%% is mandatory!

let's check what happens w/o an associated label painted etc.

Ah, that's where $labelproperties falls over. The label has to be painted, and the form has to be 'show'n, 'edit'ed or 'display'ed.

You might write a global proc cp_isnull
returns string
params
string p_string1 : IN
string p_string2 : IN
endparams

if(p_string1 = "")
return p_string2
else
return p_string1
end

and then use %%cp_isnull($item("TEXT",$labelproperties($fieldname)),"%%$fieldname%%%.%%$entname%%%")%%%

which would return the label if it knew it and the field name otherwise.

... and may be enriched by a function which returns the "standard" label text which may be specified as part of the UXFIELD or UCFIELD.

Once again a task for the dITo reflection project to make these infos available at compile time so they become part of the FRM (and SVC, RPT, ...).