Skip to main content
Is there a sneaky way to set the valreps in more than one field in the model (in different entities) to a synchronised list? Similar to the syntax or interface properties? 
I'm assuming not, but it would be really cool if the answer was sure. 
Obviously, I can set up a constant or include proc and use that to set them at runtime in every program I use them in, but it would be much cleaner to have them synchronised in the model. 
Regards, 
Iain

------------------------------
Iain Sharp
Head of Technical Services
Pci Systems Ltd
Sheffield GB
------------------------------
Is there a sneaky way to set the valreps in more than one field in the model (in different entities) to a synchronised list? Similar to the syntax or interface properties? 
I'm assuming not, but it would be really cool if the answer was sure. 
Obviously, I can set up a constant or include proc and use that to set them at runtime in every program I use them in, but it would be much cleaner to have them synchronised in the model. 
Regards, 
Iain

------------------------------
Iain Sharp
Head of Technical Services
Pci Systems Ltd
Sheffield GB
------------------------------

Hi Iain,

A question to better understand your request: I really do not focus entirely for sure what do you mean as "synchronized list".

If you mean "automatically generated", AFAIK valreps should usually be generated:
- Using a relation defined into application model (dynamic lists)
- Using a parameter enabling to read in a table a field (an occurrence really which contains a field) containing the list (fixed lists)
In both cases NULL value (positional lists) and NULL value with its custom description (associative lists) could or could NOT be part of the valreps itself, depending from context.

Regards,
Gianni



------------------------------
Gianni Sandigliano
IT
------------------------------

Hi Iain,

A question to better understand your request: I really do not focus entirely for sure what do you mean as "synchronized list".

If you mean "automatically generated", AFAIK valreps should usually be generated:
- Using a relation defined into application model (dynamic lists)
- Using a parameter enabling to read in a table a field (an occurrence really which contains a field) containing the list (fixed lists)
In both cases NULL value (positional lists) and NULL value with its custom description (associative lists) could or could NOT be part of the valreps itself, depending from context.

Regards,
Gianni



------------------------------
Gianni Sandigliano
IT
------------------------------
Hi Gianni, 

The list is hard coded, and therefore can be built into the model,. However, I would like it so that if I change the list to include a new value in the field in one entity, the field in the other entity is also updated. 
I have a list of values the user can choose (hard coded)  (e.g. Paid, Collect, Part Paid Collect on delivery, Pard Paid invoice after delivery). This is a known list, as a radio group on the transaction screen, and the same list as a behaviour modifier in the 'customer' screen, so the user can select whether an action should or should not occur for a particular customer if a particular value were chosen for the transaction. As such, the valreps for both these fields in two different entities are the same hard coded list, and I was looking to define it once, and point both fields at it. 
Regards,
Iain

------------------------------
Iain Sharp
Head of Technical Services
Pci Systems Ltd
Sheffield GB
------------------------------