callfieldtrigger and Value Changed.

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

The callfieldtrigger proc indicates that it can only be used for help, detail or menu triggers, or extended triggers, has anyone found a backdoor which enables calling value changed? We currently have a 'user defaults' data table, which is capable of storing, for any field painted on any form in our application for a particular user, a default value. When the form is loaded we read the relevant records from the defaults table, populate the fields and run validatefield for the field in order to process the fact that the user has 'changed' the data. We put the logic in the validate field trigger because you can call that code programmatically. The problem with this is that if the data is loaded from xmlload or from a struct, all these fields are marked as requiring validation, and the validate field triggers react, this causes much reloading of data and calculations which should only really be performed if the user has changed the data manually. When I saw that callfieldtrigger was coming, I thought I could use this to allow us to move the code to the VALC trigger, and change our 'defaults' proc to call the value changed trigger, but now we've upgraded to 9.5 I discover that the triggers it can call do not include this one. I don't believe I can use macro to fill in the data, as there could be many fields, on many occurrences, to default in, and that would mean having to use async or something to control the structure editor. I don't like this idea as it seems to equate to chucking balls in the air and hoping they hit their intended targets. So, I'm looking for a piece of proc which reacts to the user entering data in a field using native Uniface behaviour (which is either validate field or value changed AFAIK) and which I can call selectively if the data is filled in by other proc (which is currently validate field (validatefield XXXX) or help, menu, detail (callfieldtrigger YYY, XXX) ) but is not triggered by using proc to change the value of the field (such as xmlload, structtoComponent). Anyone?

7 Comments

  1. You probably only want to disable validation for fields modified through proc code for this one table on one form. But should you wish to have this behavior throughout your application there is an assignment setting: $VALIDATION Determine the extent of validation. $VALIDATION {=} COMPLETE | LIMITED Arguments LIMITED—use the default functionality in versions prior to V7.2. This means that declarative checks are performed when the user modifies an occurrence. COMPLETE—ensure the validation of all modified data in the component, regardless of how it was modified. Default if setting is omitted.


    Author: Theo Neeskens (tneeskens@itblockz.nl)
  2. Not exactly, validation is required. However, some code currently in the validate field trigger could do with being in the value changed trigger, because it should only be fired on user interaction. It is in the validate field trigger because we sometimes (in any of the forms in our app) use proc to simulate user interaction in order to default certain values into certain fields. I really need a simple and universal way to call the value changed trigger of a field from proc.


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  3. FiresongKt said I really need a simple and universal way to call the value changed trigger of a field from proc.

    do you want to activate the trigger or execute the code in the trigger? As part of a major refactoring project where we want to support unit tests we concentrated all proc code in a central "trigger dispatcher". In the trigger we only have the call: call dispatch_TRIGGERS("<$fieldname>","<$entname>","<$triggerabbr>",<$fieldname>) ; for fields call dispatch_TRIGGERS("","<$entname>","<$triggerabbr>","") ; for entities call dispatch_TRIGGERS("","","<$triggerabbr>","") ; for component triggers This way, we could automate all kind of tests with ease. We had special dispach_trigger calls for: UKYS ($char instead of the field value) ASYN, where we have a list of all the different message attributes


    Author: ulrich-merkel (ulrichmerkel@web.de)
  4. Well, in the case of the validatefield trigger, I want to activate it, because I need it to clear $fieldvalidation in the case of the Value changed trigger, running the proc associated with it would be good enough, as it has no effect on modification states... It works well enough now, save for the fact that xmlload and structtocomponent set $fieldvalidation. If xmlload came with a /prevalidated option or similar, life would be sweet and breezy. (Don't get me started on the other reasons xml is not fit for use to transport data between uniface components.... I am hoping structs are better, but apparently they do not currently have any easy way to manage state or reconnect to the database? )


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  5. what about using the validate and validatefield commands? 9.6.02 help reads: Description The validatefield statement validates the specified field of the current occurrence. If the field is marked as modified and has not been successfully validated or if $fieldcheck is 1, declarative checks for Field are performed and the Validate Field trigger is activated. (The section titled ‘Sequence of validation’ in the discussion of the validate statement describes the sequence and extent of declarative checks and trigger activation.) If the field is successfully validated, the Validate Field trigger sets $fieldvalidation to 0.


    Author: ulrich-merkel (ulrichmerkel@web.de)
  6. Which is why it is the trigger I am currently using for this function. However, that bangs nicely up against the fact that following a structtocomponent or an xmload every single field on the component is set for validation. So the triggers are getting activated as though the data had changed even though it (sort of) hasn't. If I save the data to xml from the service and load it again in the form, everything validates. I can only assume that the programs Uniface build don't have an issue with this because they don't use the validate field trigger, but the only way I have found round this at the moment is to code up all the validate field triggers with a component boolean indicating whether validation is a good idea right now ($in_post_load$) and to set this, then run a global validate, then unset it. All in all an unsatisfactory method.


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  7. in 7.2, only manual changes were validated while changes via proc were not checked. perhaps the $VALIDATION ASN setting to LIMITED (as Theo has recommened) can bring back the good times for us. If it doesn't work for XML load and Struct2component, raising a bug call may be worth a try. Would be much batter than all that fake validation with $in_post_load$ we would have to implement to work around that problem. Well, the dispatch_triggers could ease the implementation because we have a central place to catch the situation there: if (p_triggerabbr = "VLDF" & $in_post_load$) return(0)


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