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.

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.

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

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? )

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.

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.

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)