 when-validate-item trigger fires multiple times [message #642106] |
Wed, 02 September 2015 12:19  |
arobinson98
Messages: 8
Registered: June 2005
|
Junior Member |
|
|
Okay here's the scenario, I've got a form with multiple related blocks, lets say B1 is parent, and B2 is child of B1, and B3 is child of B2. I query for a record and B1 populates and B2 populates and there are no records in B3. B3 has 2 items and I then enter a value in each item. When I get to the second item there is a when-validate-item trigger that checks for a valid value and if not valid, displays a message and raises form_trigger_failure. When I move out of the item the trigger fires and the message displays just fine. However if I attempt to save the record, the message displays 3 times (I'm guessing the when-validate-item trigger fires 3 separate times). If I move the validation code to a key-commit trigger at the form level and hit save it just displays the message one time. So my question is this.
Why would a when-validate-item trigger on an item fire multiple times when a form is committed? What would cause that trigger to fire again once it has already fired?
|
|
|
|
|
|
| Re: when-validate-item trigger fires multiple times [message #642132 is a reply to message #642110] |
Thu, 03 September 2015 08:22  |
 |
CraigB
Messages: 386
Registered: August 2014
Location: Utah, USA
|
Senior Member |
|
|
What is your Forms version? Are you setting values in the W-V-I trigger? Can you give us a code sample? Where there any changes in the Parent or Grandparent blocks?
Quote:What would cause that trigger to fire again once it has already fired?
Basically, the Forms validation unit is firing at each level of change (Child, Parent, and Grandparent) in response to the status of each level (FORM_, BLOCK_ and RECORD_STATUS). You might want to add a Debug Message to your W-V-I trigger that displays each of these System Status variables, eg:
Message('Form: '||:SYSTEM.FORM_STATUS||', Block: '||:SYSTEM.BLOCK_STATUS||', Record: '||:SYSTEM.RECORD_STATUS);
Message(' ');
If all three are CHANGED, INSERT or NEW then you have changed something at each level. Check all of your code to see if you are altering anything at each level. This could account for why the W-V-I trigger fires 3 times.
Running your Form from the Forms Builder in Debug Mode (as LF suggests) is also a great troubleshooting step.
Craig...
[Updated on: Thu, 03 September 2015 08:23] Report message to a moderator |
|
|
|
| Re: when-validate-item trigger fires multiple times [message #642144 is a reply to message #642132] |
Thu, 03 September 2015 12:42 |
cookiemonster
Messages: 13963
Registered: September 2008
Location: Rainy Manchester
|
Senior Member |
|
|
Craig - you appear to be confusing the relationship of the three blocks and the form/block/record relationship
Changing a record changes the block, changing a block changes the form. This is by definition.
So if you query some records, change an item and then do your suggested check, I'd be very worried if all three statuses weren't CHANGED. There is no way that should lead to WVI firing multiple times
I can imagine the master-detail relationship causing the validation to fire multiple times though.
@arobinson98 - in the WVI display the block status of all three blocks using get_block_property, as well as form_status and record_status, that may provide some clues.
|
|
|
|
|
|
| Re: when-validate-item trigger fires multiple times [message #642709 is a reply to message #642666] |
Thu, 17 September 2015 08:55 |
|
CraigB
Messages: 386
Registered: August 2014
Location: Utah, USA
|
Senior Member |
|
|
Quote:In post query trigger, use this
set_item_property('block.item_name', item_is_valid, property_true);
This is will mark the item as valid and will not execute WVI unless you update it and or delete/add something new.
THis just "Masks" the problem - it doesn't eliminate it. The better option is to find out what is changing the status of the ITEM or RECORD and modify this logic to "NOT" change the status.
@ CM,
Quote:So if you query some records, change an item and then do your suggested check, I'd be very worried if all three statuses weren't CHANGED.
I've actually seen this scenario where the ITEM and BLOCK statuses are "CHANGED" but the FORM status is "QUERY". I agree that this shouldn't happen and if you are manipulating values through the UI then this is the case, but when you are setting values behind the scenes through code, I've seen this happen.
[Updated on: Thu, 17 September 2015 08:59] Report message to a moderator |
|
|
|
| Re: when-validate-item trigger fires multiple times [message #642712 is a reply to message #642709] |
Thu, 17 September 2015 09:12 |
cookiemonster
Messages: 13963
Registered: September 2008
Location: Rainy Manchester
|
Senior Member |
|
|
CraigB wrote on Thu, 17 September 2015 14:55Quote:In post query trigger, use this
set_item_property('block.item_name', item_is_valid, property_true);
This is will mark the item as valid and will not execute WVI unless you update it and or delete/add something new.
THis just "Masks" the problem - it doesn't eliminate it. The better option is to find out what is changing the status of the ITEM or RECORD and modify this logic to "NOT" change the status.
No.
If you're populating non-database, non-display items in post-query than that code is a basic necessity and should always be done. There's no point forms re-validating and trying to save stuff that has actually been retrieved from the DB.
If you're not populating such items post-query then that code will do nothing and is a waste of time.
Nothing in the OPs post indicates he's populating such items.
CraigB wrote on Thu, 17 September 2015 14:55
@ CM,
Quote:So if you query some records, change an item and then do your suggested check, I'd be very worried if all three statuses weren't CHANGED.
I've actually seen this scenario where the ITEM and BLOCK statuses are "CHANGED" but the FORM status is "QUERY". I agree that this shouldn't happen and if you are manipulating values through the UI then this is the case, but when you are setting values behind the scenes through code, I've seen this happen.
[/quote]
If you're messing around with the various built-ins that set form/block/record status directly then sure you can end up in a situation like that, and who knows the OP might be (doubt we'll find out at this). Absent use of those functions it really shouldn't and I've certainly never seen it, though for all I know they may be a forms bug that lets it happen.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
