By using this website, you agree to our Terms of Use (click here)
Regarding the following Acumatica Event Handlers:
1. FieldSelecting
2. FieldDefaulting
3. FieldVerifying
4. FieldUpdating
5. FieldUpdated
I'm taking some notes for myself here so I can refer back to them in the future.
I am NOT a developer and I still refuse to work in Visual Studio. It's too complicated for me. But I can do some light coding stuff through the Acumatica Customization Projects (SM204505) screen in my web browser. There are a lot of options that you can set there. Especially interesting is the EVENTS tab that you see when you click on a field:
All of those Event are specific to the field that you clicked on. In my screenshot above, I clicked on the Alternate ID field. But you can override the behavior of an Event by highlighting the Event (I did FieldSelecting in the screenshot above) and clicking the ADD HANDLER drop-down which gives you two options: Keep Base Method and Override Base Method.
If you select Keep Base Method, then Acumatica will generate something in the CODE area of your Customization Project that looks like this:
If you select Override Base Method, then Acumatica will generate something in the CODE area of your Customization Project that looks like this:
You can see that the two screenshots above are similar, but not the same. Despite the names, I think they actually do the opposite of what they say. As far as I can tell, the Keep Base Method code will replace what Acumatica normally does with whatever code you want and Override Base Method code will add extra stuff to what Acumatica normally does. At least that's how I think it works, the opposite of what the names imply.
Then it becomes a question of which Event you want to modify. That's where we come back to this list:
1. FieldSelecting
2. FieldDefaulting
3. FieldVerifying
4. FieldUpdating
5. FieldUpdated
When does each one get used?
I did some digging in the Acumatica help and am summarizing my notes here.
What Events get executed and what order they get executed in depends on what you're doing with a record on the screen. This is what it says in the Help:
1. Update - FieldUpdating -> FieldVerifying -> FieldUpdated
2. Insert - FieldDefaulting -> FieldUpdating -> FieldVerifying -> FieldUpdated
3. Delete - FieldUpdating -> FieldUpdated
4. Display - FieldSelecting
And there is a nice diagram which you find here:
https://help-2018r2.acumatica.com/Help?ScreenId=ShowWiki&pageid=d9cf6274-f5c8-43e7-9d13-9b423113d67e
What complicates things is the Attribute on the field which, as far as I understand it, are more related to the Field DAC (Data Access Class) than they are to the Screen. The Attribute has its own Event Handlers associated with it. Sometimes it gets called before the Field Event, sometimes after, or sometimes not at all if you set Cancel to true. The Attribute still makes my head hurt and I don't want to take notes on it here, but here are the help articles with the details of when the Attribute Event Handlers get called for future reference:
1. Update - Gory Details
2. Insert - Gory Details
3. Delete - Gory Details
4. Display - Gory Details
What I'm wondering right now is why there are two Events (FieldUpdating and FieldUpdated) instead of one. Hmmm, not sure yet.
In the two code screenshots above, there is something called PXFieldSelectingEventArgs. You can use that to reference some useful things.
What you can reference with PXFieldSelectingEventArgs depends on what Event Handler you're using.
1. FieldSelecting - ExternalCall, IsAltered, ReturnState, ReturnValue, Row (click here for more info)
2. FieldDefaulting - NewValue, Row (click here for more info)
3. FieldVerifying - ExternalCall, NewValue, Row (click here for more info)
4. FieldUpdating - NewValue, Row (click here for more info)
5. FieldUpdated - ExternalCall, OldValue, Row (click here for more info)
why there are two Events (FieldUpdating and FieldUpdated) instead of one.
In order to find out, I want to give my viewpoint.
FieldUpdated is executed after the field is changed in the cache. FieldUpdating is triggered before the value of the field is set.
As outcome, FieldUpdated gives me, as a developer mechanism to react on event when field is changed. Examples:
1. If value is zero, execute one logic
2. If value is greater then zero execute another logic
3. If value is negative, execute another logic.
FieldUpdating allows me to execute some logic before some value is set and potentially prevent from setting value to something, that goes against business logic. Sometimes developer may use FieldUpdating in a wrong way ( i.e. Validation logic, for this purpose should be used FieldVerifying ), but most common scenario is if such and such field is going to receive value, trigger some other changes. Another example of FieldUpdating usage is assigning default value, formatting or converting.
I do admit, that it is kind of slight difference, and there are plenty of use cases when these events may be used instead of each other withouth difference. And I'm bet there are a lot of cases when it is used.
To put simply: FieldUpdating is about preparing and validating the new value, while FieldUpdated is about reaction on the change that already occured.
Thank you Yuriy. This is helpful.