Skip to main content

reconnect and $fieldvalrep

  • January 20, 2021
  • 4 replies
  • 0 views
Iain Sharp
Forum|alt.badge.img+5

I have some dropdown lists in my form, the valrep of which is dependant on the data. 

I am setting the $fieldvalrep in the postdeserialise trigger and the program is holding this, until it hits the reconnect to reset the modification status, when it wipes them all. 

  1. Why is the $fieldvalrep reset? 
  2. How can I program something in the model to ensure the valreps are set correctly for each occurrence on loading the data and/or creating a new occurrence? I obviously don't want to have to do a loop through all occurrences after loading to set the $fieldvalrep as this is a waste of time and if there's one thin UNiface isn't it's fast. 

This is the third problem I've encountered with reconnect resetting values (for non-db fields such as totals) or states (setting fields to modified when they shouldn't be) and at least some of these behaviours are different in 10 than in version 9. 

Anyone else found/solved similar issues? 


Iain

Iain Sharp : Head of Technical Services, Jonas Metals Software

4 replies

Norbert Lauterbach
Forum|alt.badge.img+3

I have some dropdown lists in my form, the valrep of which is dependant on the data. 

I am setting the $fieldvalrep in the postdeserialise trigger and the program is holding this, until it hits the reconnect to reset the modification status, when it wipes them all. 

  1. Why is the $fieldvalrep reset? 
  2. How can I program something in the model to ensure the valreps are set correctly for each occurrence on loading the data and/or creating a new occurrence? I obviously don't want to have to do a loop through all occurrences after loading to set the $fieldvalrep as this is a waste of time and if there's one thin UNiface isn't it's fast. 

This is the third problem I've encountered with reconnect resetting values (for non-db fields such as totals) or states (setting fields to modified when they shouldn't be) and at least some of these behaviours are different in 10 than in version 9. 

Anyone else found/solved similar issues? 


Iain

Hello Iain,


maybe you are  using the wrong function?

$fieldvalrep is for a single occ.

$valrep is for all occs.


Regards

Norbert


J
Forum|alt.badge.img
  • John Bergsma
  • Participating Frequently
  • January 20, 2021

I have some dropdown lists in my form, the valrep of which is dependant on the data. 

I am setting the $fieldvalrep in the postdeserialise trigger and the program is holding this, until it hits the reconnect to reset the modification status, when it wipes them all. 

  1. Why is the $fieldvalrep reset? 
  2. How can I program something in the model to ensure the valreps are set correctly for each occurrence on loading the data and/or creating a new occurrence? I obviously don't want to have to do a loop through all occurrences after loading to set the $fieldvalrep as this is a waste of time and if there's one thin UNiface isn't it's fast. 

This is the third problem I've encountered with reconnect resetting values (for non-db fields such as totals) or states (setting fields to modified when they shouldn't be) and at least some of these behaviours are different in 10 than in version 9. 

Anyone else found/solved similar issues? 


Iain

Hello Iain,


The $fieldvalrep's, and $occproperties too, are wiped because it's occurrence dependent. With reconnect, but also clear and retrieve, the occurrence specific settings are lost. This is also documented.

You could try saving the $fieldvalreps in a component variable just before the occurrences are cleared and refill in the PostDeserialize trigger, otherwise a loop is the only way. We use an operation which is called from the read trigger after a successfull read statement to set the $fieldvalrep.


Hope this helps / explains the problem you describe.


With kind regards,


John

Iain Sharp
Forum|alt.badge.img+5
  • Iain Sharp
  • Author
  • Inspiring
  • January 20, 2021

Hello Iain,


maybe you are  using the wrong function?

$fieldvalrep is for a single occ.

$valrep is for all occs.


Regards

Norbert


And this valrep can be occurrence dependant. (it's a list of currently valid values, but must be able to include a historic value no longer valid, if it matches the current value of the field. 

So last year the possibles were A, B, C. This order item was set to B. This year the valid values are A, C, & D. But when viewing an order from last year, the valrep must include B.... (Simplified example)

So it's got to be $fieldvalrep. 

Iain Sharp : Head of Technical Services, Jonas Metals Software
Iain Sharp
Forum|alt.badge.img+5
  • Iain Sharp
  • Author
  • Inspiring
  • January 20, 2021

Hello Iain,


The $fieldvalrep's, and $occproperties too, are wiped because it's occurrence dependent. With reconnect, but also clear and retrieve, the occurrence specific settings are lost. This is also documented.

You could try saving the $fieldvalreps in a component variable just before the occurrences are cleared and refill in the PostDeserialize trigger, otherwise a loop is the only way. We use an operation which is called from the read trigger after a successfull read statement to set the $fieldvalrep.


Hope this helps / explains the problem you describe.


With kind regards,


John

I am already populating the $fieldvalreps in the postdeserialise trigger, as the values of the valreps are dependant on the data in the occurrences as loaded. 

So the values are set correctly after the structtocomponent, but then it hits a reconnect to set the modification status and the $fieldvalreps are wiped again. 

There is NO read trigger fired in this code, as it is a form, loaded from a service in client server mode using the $collhandle→load() (but using structs not xml as in the default CS behaviour). 

What I need is a method of building (e.g. total value) in a sales order record, as a result of deserialising the sales order items (so adding up the item value as it is loaded into the screen). Because the non-database total field is in the model, (so that I can write model level code using it), it is WIPED by the reconnect even though it is built correctly by the postdeserialise. What I've had to do here is to build the total(s) into a struct, and then call a proc to populate the fields in the one entity after the reconnect, which is okay, because that's only affecting one occurrence. 

Similarly, these $fieldvalreps are wiped by the reconnect, and there is no trigger fired by the reconnect during which these values could be recalculated. Updating them involves a loop through 10s or 100s of occurrences, that the system has already looped through on the postdeserialise. 

Such a waste of effort. 

Iain Sharp : Head of Technical Services, Jonas Metals Software

Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement