Quick Tip: Capturing the Save Event with Visual Studio Tools

I recently responded to a community post which was asking how to ensure that all save events from the Item Maintenance window were captured using Visual Studio Tools. The aim was to make sure that the additional fields added to the window with Modifier were saved when the item data in the window was saved.

The developer had already captured the save event when the Save Button was clicked using the event Dynamics.Forms.IvItemMaintenance.IvItemMaintenance.SaveButton.ClickBeforeOriginal.

However, this does not capture the save event when the lookup button was used; one of the four browse buttons was used; or a zoom to the window from another window occurred. In each of these six situations (if the window contents have been changed), the "Do you want to Save, Discard or Cancel?" dialog (or equivalent) will open. Then if the save button on the dialog is pressed, the data will be saved and this will NOT be captured by the Save Button event.

Here are some examples for the save dialogs from the Item Maintenance, Customer Maintenance and Sales Transaction Entry windows, respectively:

Note: For details on the last window has Delete instead of Discard see: Why can't I discard changes on a Transaction?

So the question is how do you make sure you capture the save event from the dialog as well as the Save Button?

---

The answer is that you have two methods in how you can handle this. You can use the method that a Dexterity developer would use, or you can use the method that a Visual Basic for Applications (VBA) developer would use.

 

Dexterity Method

As discussed above, there are at least 7 possible user interface events which can cause a record to be saved (Save Button and events which use the dialog). I say at least 7 as we have not included buttons for Print, Post or other activities. However, all of these user interface events end up calling a single save script. This script might be a field change script or a form level function or procedure. You can use Dexterity Script Logging (via Debug menu at runtime or Support Debugging Tool) to capture the Save Record script and identify which it is a field change script or form level function or procedure.

In our case, we can use the Dynamics.Forms.IvItemMaintenance.IvItemMaintenance.SaveRecord.ValidateAfterOriginal event instead of the Save Button event and check that the value of the Save Record field has been set to true for record saved successfully. Triggering after this event will capture all saves for the window regardless of what user interface event started the process.

 

VBA Method

In VBA, you would use the Window_AfterModalDialog() event to trigger when Save was selected from the Save, Discard or Cancel dialog in addition to watching for the Save, Print, Post Buttons etc. You would have to make sure you capture all the locations where a save can occur.

In our case, we could use the Dynamics.Forms.IvItemMaintenance.IvItemMaintenance.AfterModalDialog event to capture the Dialog response and check if the user clicked the first "save" option. We would still need to also track the other buttons separately.

 

My recommedation is the use the Dexterity Method as it is the most reliable and the simplest. It will capture all save events with a single trigger. 

Also, if the Save Record script is using a Field Change script, you can also use this method with VBA. As VBA cannot trigger off functions and procedures, it does not work for the other script types. To use it, you need to add the hidden Save Record field to VBA; either temporarily make the field visible and place it into the visible part of the window; or use the unsupported method of editing the package file with notepad.exe to change references to the Save Button field to the Save Record field.

 

Hope you find this tip handy. 

David

Comments

• Anonymous
  February 26, 2014
  The comment has been removed
• Anonymous
  February 26, 2014
  The comment has been removed