Hi All,
As you may know from, Acumatica events are triggered in the specific sequence. But there is sequence not only for event types, events for different row and field will be triggered within a specific sequence too.
Rows
With rows it is a bit easy:
Insert/Update happens in the sequence how it was triggered. If you update a value it will trigger an event sequence for specific cache that was updated. In case event updates other caches, that they will be triggered also as soon as cache.Update/Insert/Delete is called.
Save/Delete happens for primary cache first as it is associated with the button, than it will call PXParent Attributes in the sequence how DataView defined. So to stress it – it is important how you put your PXSelect<>s in the Graph – it will define sequence for saving/deleting records.
Fields
For fields declaration sequence is also very important. Field events will be triggered exactly in the sequence of declaration in the DAC. So if you Put Customer first and than Location, location field Defaulting/Updated will happen after customer and can use it’s value. If you put it in the reverse order, you may find Location empty.
However within customization we may need a way to influence fields event sequence. Unfortunately we can’t change the declaration order, so we have a different way to do it – Tab Orders.
#region DocType
[PXDBString(3, IsKey = true, IsFixed = true)]
[ARInvoiceType.List()]
[PXUIField(DisplayName = "Type", Visibility = PXUIVisibility.SelectorVisible, Enabled = true, TabOrder = 0)]
public override String DocType {get; set;}
#endregion
You see here “TabOrder = 0” this advises Acumatica Framework that field event for “DocType” should be triggered with first.
Using TabOrders in your DAC Extensions, you can set and change event execution flow for fields you customize.
As far as I know this option does not exist for rows.
However be careful, as changing event sequence flow may break an existing logic. Like, for example, I have found this functionality when I accidentally copied CustomerLocation attribute to my customization with the wrong order. Than I realized that location updates before customer. With great power it is easy to break something 🙂
Have an easy development!
Thank you for this information. My first guess for controlling the order of field events was to set the FieldOrdinal property for each PX field attribute eg [PXDBInt(FieldOrdinal = 1)], [PXDBString(FieldOrdinal = 2)]… and I was a little surpised when that didnt work. I am a little more surpised to learn it is the TabOrder property of the PXUIFieldAttribute that controls this order of events.
What does manually setting the FieldOrdinals for fields in a DAC actually do?
Paul,
FieldOrdinal is actually an internal field that identifies the sequential number of the column in the SQL Querry. It is needed as accessing (setting and getting) the field up by Integer is faster than by String.
So the field is managed by the internal Acumatica logic.
That makes sense, thank you!