An example of this is VB code that will be required to run after we have a done a TL Selector post to Syspro. There are various places where after a core TransLution button is clicked, VBP code can be run. In this type of scenario, there is no new button created. This is commonly used when a post is done from data logged to a TransLution table to change the status of the rows to sow that they have been posted in order to prevent duplicate posts. As before, the process starts by activating the button on the Form and Button Maintenance form. 

 

The user finds the appropriate button (in this case btnPostToSyspro) and activates it as shown below. Note that in this case because there is no button visible as a result of this process, there is no need to define a Button Description and the field can simply left blank.

 

The most common buttons for this are the OK and Finish buttons.

The buttons are enabled as shown below and then they are linked to a function area using the VBP Mapping form. This means that when OK is clicked on any prompt in a given function area, the same VBP code will be executed. When Finish is clicked, the VBP code for that function area will be executed.

 

 

 

The button then has to be linked to the correct VB Provider code exactly as was done previously using the button mapping form as shown below. In this case it is pretty much always that you would link the code to a specific function area and not make it general. Also, here the option Refresh TL Selector Grid becomes relevant. Say for example, all the rows in a table that are unprocessed and in a status of 5 are shown on the TL Selector Grid. Once data has been posted to Syspro, in order to prevent users re-posting the same data, we would want to change the line status to 10. The VBP code would do this for us and the Refresh option would refresh the grid so that the lines just processed disappear off the grid.

 

VBP Mapping