Recently, our testing team reported a recurring issue with my custom screens that proved to be a bit more than frustrating. As users update fields and press Save or some Action, the user updates may be lost. The obvious problem to check is the proper use of CommitChanges, or lack thereof. When using CommitChanges = true on a field in the ASPX file, we introduce a little extra overhead while the page, well, commits the changes entered. Overuse carries overhead that wastes system resources when it isn’t strictly necessary. Even when overusing in attempt to force the data entry to commit, we found that the data isn’t committed unless the user clicks off of the field before continuing to click Save or an Action. Certain that I must have overlooked something basic, I decided it was time to go back to the training guides.
The T230 – Actions training guide specifically speaks to the use of CommitChanges on custom actions. Specifically, on the PXButton attribute in the C# code and on the DataSource in the ASPX file. Unfortunately, it is written from the perspective of modifying a standard Acumatica page, and not writing a completely new one. What it fails to mention is the need to place CommitChanges = true on the Actions menu and Save buttons themselves. More on that in a moment.
Having reviewed the training guide again, I went to Stack Overflow, a place I suggest any developer in the Acumatica community visit often to seek and lend developer support. My posted question (acumatica – How do I force user input to commit and save automatically when executing an action? – Stack Overflow) took a couple of days to get a response. The answer was quite surprising, so kudo’s to User Parmisean – Stack Overflow for figuring it out… Menu actions (Save, Actions, etc.) that depend on a user entry to be captured first ALSO must be instructed to Commit Changes in the ASPX file.
See the following from the Acumatica Framework Developer Guide for 2019R2.
Why is this happening?
A webpage in Acumatica is a structured layout of fields ultimately tied to database fields in a database server. The interaction between the user and the database is managed by all of the layers in between. The web browser contains events that can be hooked so that user interactions cause a reaction within the system. In the early days of input forms on basic websites, most forms simply collected data until the user clicked a Submit button. The web browser would send the data in the form to the server and wait for a response to provide the “next step”. When this got more sophisticated (by the early standards) then the website would use that form input to populate a fresh web page (possibly just a new version of the current page) with “next steps” types of changes, like picking the make of your car and then the server asking what model on the next (or updated) page.
Jump ahead 20+ years, and webpages have become far more sophisticated. What used to be handled by passing data back and forth in a fairly clunky way has been replaced by pages that dynamically update while form data is “posted back” when instructed by the program, such as our Commit Changes setting. Ultimately, the form data is held at the browser, sent back to the server when callbacks are required, and updated by responses to these callbacks. Each time the form data is sent, the form is updated with the response from the callback. Read that again… Each time the form data is sent, the form is updated with the response from the callback. If something happens in the browser before this callback and response can be processed, the change is lost. In other words, if you send the form data for a commit changes, while you also press the save button without the commit changes, then your initial commit changes is lost because the updates have not had time to make it back to the browser to be included in the form data sent back with the save or action button. Simply put, without CommitChanges on the Save or Action, the browser simply instructs the server to perform the specified action, not to commit changes made in the form.
So what does this really mean for creating new custom graphs/web pages in Acumatica? Simply put, always remember to add Commit Changes = true to Save and the Actions menu when used in the CallbackCommands section at the top of your ASPX file.
<CallbackCommands>
<px:PXDSCallbackCommand CommitChanges="True" Name="Action" >
</px:PXDSCallbackCommand>
<px:PXDSCallbackCommand CommitChanges="True" Name="Save" >
</px:PXDSCallbackCommand>
</CallbackCommands>Happy coding!