Skip to main content

Inherit/Share Valrep

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

We have several fields in different entities which logically need to share a valrep. (Values provided by customs and excise, needs to be stored at supplier, order and receipt level.) Customs recently changed the list, and one of our devlopers was cought out, when they changed two of the three fields to have a new valrep, data defaulted from one field to another could no longer be updated into the database. The UI did not have the field painted, so the user was stuck and couldn't update the data.  Is there a way of setting up a valrep IN THE MODEL, which is 'shared' in some way between these three fields? i.e. a central copy is updated and they are all refreshed?  I am aware we could remove the valrep for the drop down list, and implement it in the UI from (for example) a global constant, but I'd prefer if the inclusion of the field from the model did all the work for us. 

Inherit/Share Valrep

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

We have several fields in different entities which logically need to share a valrep. (Values provided by customs and excise, needs to be stored at supplier, order and receipt level.) Customs recently changed the list, and one of our devlopers was cought out, when they changed two of the three fields to have a new valrep, data defaulted from one field to another could no longer be updated into the database. The UI did not have the field painted, so the user was stuck and couldn't update the data.  Is there a way of setting up a valrep IN THE MODEL, which is 'shared' in some way between these three fields? i.e. a central copy is updated and they are all refreshed?  I am aware we could remove the valrep for the drop down list, and implement it in the UI from (for example) a global constant, but I'd prefer if the inclusion of the field from the model did all the work for us. 

Yeah, thanks Uli. I had come up with both those ideas myself. I was looking for something a little more 'fire and forget'....  I am just a little disappointed that field templates don't provide inheritance after application, and in the lack of inheritance between things like the supertype and the entity sub-types. (not even the labels inherit....) It's all right if the specifications don't change, but if you live in such a static world, you soon run out of things to do....    Iain


Author: Iain Sharp (i.sharp@pcisystems.co.uk)

Inherit/Share Valrep

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

We have several fields in different entities which logically need to share a valrep. (Values provided by customs and excise, needs to be stored at supplier, order and receipt level.) Customs recently changed the list, and one of our devlopers was cought out, when they changed two of the three fields to have a new valrep, data defaulted from one field to another could no longer be updated into the database. The UI did not have the field painted, so the user was stuck and couldn't update the data.  Is there a way of setting up a valrep IN THE MODEL, which is 'shared' in some way between these three fields? i.e. a central copy is updated and they are all refreshed?  I am aware we could remove the valrep for the drop down list, and implement it in the UI from (for example) a global constant, but I'd prefer if the inclusion of the field from the model did all the work for us. 

Hi Iain, thats the good(?) old problem since we had field-templates: part of it is just like a stamp while others are true inheriting the changes. Remember the good old way to enter the interface for fields where you could enter either C20 or @myClong; would be nice to have the same option for valreps. In DUR, as we were providing some automatic propagation of INIT and CLEANUP and use a couple of #defines on entity level to control this, it's nearly "define and forget". Greetings from Frankfurt/Germany, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)

Inherit/Share Valrep

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

We have several fields in different entities which logically need to share a valrep. (Values provided by customs and excise, needs to be stored at supplier, order and receipt level.) Customs recently changed the list, and one of our devlopers was cought out, when they changed two of the three fields to have a new valrep, data defaulted from one field to another could no longer be updated into the database. The UI did not have the field painted, so the user was stuck and couldn't update the data.  Is there a way of setting up a valrep IN THE MODEL, which is 'shared' in some way between these three fields? i.e. a central copy is updated and they are all refreshed?  I am aware we could remove the valrep for the drop down list, and implement it in the UI from (for example) a global constant, but I'd prefer if the inclusion of the field from the model did all the work for us. 

Hi Iain, in the Collection Operations, model some INIT operation which set the valreps from a precompiler constant or so. In the component INIT operations, just activate these operations for all painted entities. $collhandle("myentity1")->INIT() We created this pattern in the context of the dITo Uniface Refelection (DUR).   Another option would be a tiny component modifying the UCFIELD.DICT for all these fields concerned. Think with all your experience, it should not be hard to get this utility working.   Greetings from Frankfurt/Germany, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)

Inherit/Share Valrep

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

We have several fields in different entities which logically need to share a valrep. (Values provided by customs and excise, needs to be stored at supplier, order and receipt level.) Customs recently changed the list, and one of our devlopers was cought out, when they changed two of the three fields to have a new valrep, data defaulted from one field to another could no longer be updated into the database. The UI did not have the field painted, so the user was stuck and couldn't update the data.  Is there a way of setting up a valrep IN THE MODEL, which is 'shared' in some way between these three fields? i.e. a central copy is updated and they are all refreshed?  I am aware we could remove the valrep for the drop down list, and implement it in the UI from (for example) a global constant, but I'd prefer if the inclusion of the field from the model did all the work for us. 

Valreps are always connected to relationships, physical or logical ones; it should not be too difficult to have them declarative with the possibility to concatenate 1-3 fields as value in the key=value association. A simple list at component level could have them loaded automatically when each component is created (static) or activated (dynamic). If this is not the desired behaviour we could always rely on coding mode. Gianni


Author: gianni (gianni.sandigliano@unifacesolutions.com)

Inherit/Share Valrep

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

We have several fields in different entities which logically need to share a valrep. (Values provided by customs and excise, needs to be stored at supplier, order and receipt level.) Customs recently changed the list, and one of our devlopers was cought out, when they changed two of the three fields to have a new valrep, data defaulted from one field to another could no longer be updated into the database. The UI did not have the field painted, so the user was stuck and couldn't update the data.  Is there a way of setting up a valrep IN THE MODEL, which is 'shared' in some way between these three fields? i.e. a central copy is updated and they are all refreshed?  I am aware we could remove the valrep for the drop down list, and implement it in the UI from (for example) a global constant, but I'd prefer if the inclusion of the field from the model did all the work for us. 

Option A) In the defines triggers of the 3 fields, include a single/central include proc that contains a defines for the valrep. Option B) Create a message that contains the valrep. (This is what is used in the Uniface IDF) For both options you would still need to find a nice place to assign the valrep to the field.   If you enter a wish for a better solution, I'll vote for it.


Author: Theo Neeskens (tneeskens@itblockz.nl)

Inherit/Share Valrep

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

We have several fields in different entities which logically need to share a valrep. (Values provided by customs and excise, needs to be stored at supplier, order and receipt level.) Customs recently changed the list, and one of our devlopers was cought out, when they changed two of the three fields to have a new valrep, data defaulted from one field to another could no longer be updated into the database. The UI did not have the field painted, so the user was stuck and couldn't update the data.  Is there a way of setting up a valrep IN THE MODEL, which is 'shared' in some way between these three fields? i.e. a central copy is updated and they are all refreshed?  I am aware we could remove the valrep for the drop down list, and implement it in the UI from (for example) a global constant, but I'd prefer if the inclusion of the field from the model did all the work for us. 

Iain, I normally solve these by having a 'global' config table in the background - simply because there will always be a need to change data - even the data that 'never' change! Field1 = config_name Field2 = varchar(*) - contains whatever - in this case, value list of what's needed. In model code - for each of the 3 or more fields - in 3 triggers (OGF, DECR and VALF); OGF - no retrive done (yet) DECR - retrieve fired from somewhere else (relationship) VALF - in case occurence loaded via list/struct/xml if (!$valrep("%%$fieldname%%%.%%$entname") activate xxx.get_data_from_config_table(config_name, return_data) ; (or store in global variable and reuse) $valrep("%%$fieldname%%%.%%$entname") = return_data endif Of course, the code would/should be an include proc... Knut


Author: Knut (knut.dybendahl@gmail.com)
Terms & ConditionsAccessibility statement