| Formats in PeopleCode Variables | KEVIN RESCHENBERG
01-30-2008 |
My client found this oddity and it's something I had never seen before.
A page contained a field that had a field format attached (Format Type = Custom, Family Name = PHONE,
Display Name = NORMAL). In FieldChange this field was passed to a PeopleCode function defined
in another PeopleCode program (FieldFormula). Within
the definition of the function, the value was received using a normal variable like this:
In FieldFormula:
function MyFunction(&Phone);
...
end-function;
In FieldChange:
MyFunction(MY_RECORD.MY_FIELD);
Now, the odd thing is that &Phone didn't act like a string variable.
If we gave it a value that included a number in parentheses, for example, and then
immediately inspected the variable, the parentheses would be gone. The variable was applying
the formatting rules. We tried redefining the function like this:
function MyFunction(&Phone as String);
But that didn't make any difference. We also tried passing in the
value of the field (MY_RECORD.MY_FIELD.Value), thinking that would turn it into a regular
string, but no good. On the other hand, a field
defined with a format of UPPERCASE didn't seem to cause the same behavior—we could
send mixed-case values into the &variable and they would "stick."
A new variable could be created (Local String &Other) and set to the value of the &Phone
variable, and the new variable would accept any value. But passing it back into &Phone
caused the formatting to be applied to &Phone.
I'm surprised by all of this. Apparently a &variable that contains a value (as opposed to an object reference)
is not always a standalone storage area
but is sometimes a way of referring more directly to an object such as a field.
|
