Tips for Migrating Your VBA Code to a GP Dot Net Add-on

Recently we had the task of getting a large number of customization that had been created using VBA and Modifier to function on the GP2015 Web Client. Since VBA will not function on the web client, we had the option of re-writing the functionality in Dexterity or Dot Net. Our development team is mainly focused on Dot Net, with a few of us that are well versed in Dexterity. For this reason, we decided that Dot Net would be the best tool to use in this update, and ongoing support in the future.

There were a few interesting issue that came up while re-writing the code from VBA to C# which I would like to present here, hopefully to save you a headache in the future.

1.     Not all the events in VBA are available in Dot Net

VBA has the events ‘BeforeUserChanged’ and ‘AfterUserChanged’ on GP Fields. This is not available in Dot Net; you only get the ‘Change’ event. This change event will fire whether the user makes a change to the field or some other code makes a change; this can cause a problem when you are setting values of a field from code.

Dot Net has the events ‘ValidateAfterOriginal’ and ‘ValidateBeforeOriginal.’ These are your best bet instead of using the ‘Change’ event. They will fire when the field value changes and you can intercept before the GP code goes off with the ‘Before’ event.

2.     The GP Fields script does not always run

In VBA when you change a field through code, the GP code behind the field goes off automatically. This does not appear to be the case when using Dot Net code. To ensure that the GP code goes off properly, call the ‘RunValidate’ method of the GP Field in your Dot Net code. This will run the GP code behind the field as if the user had changed the value through the UI, just like how the VBA code used to function.

3.     Field names do not match the VBA field names

This one ends up being just trial and error for the most part. If the field name is significantly different, it can be difficult to track down the exact right field name. Usually they are similar enough that you will be able to figure it out. For example, the field ‘CustomerID’ in VBA on the customer maintenance screen, becomes ‘CustomerNumber’ in Dot Net; that’s an easy one. Most of them are as easy as that, but some are very different. When looking for the proper field, it is probably easiest to open the screen in modifier and check the field name there.

Local fields – fields that are local to the screen in question – will have the name word ‘Local’ before the field name. For example, if you have a local field called ‘NewField’, in Dot Net the field will be called ‘LocalNewField.’

4.     Event Arguments instead of CancelLogic

In Dot Net, the events that you register on ‘EventHandler’ will usually have two parameters:  ‘Sender’ and ‘EventArgs.’ The ‘Sender’ is an object which is the field that caused the event to fire. The ‘EventArgs’ are arguments passed to the event.  For the most part I have not had a need to use the ‘EventArgs’ in my code. However, some events have a different ‘EventArgs’, called ‘CancelEventArgs.’ These are usually found on the ‘Before’ events. You can use these to cancel the GP code from running, much like how you would set ‘CancelLogic=true’ in VBA. Now it would be ‘CancelEventArgs.Cancel=true.’

I am sure there are many other issue people have run into while converting their VBA to Dot Net, but these are the main ones that I have run into while actually writing the code. I hope this article will assist anyone converting from VBA to Dot Net; at least it might relieve a headache or two.

---

WILL STAFFORD | .Net Business Solutions Team Leader

Will is responsible for the creation and maintenance of software customizations, reports and applications. He works on the entire development life cycle, gathering requirements, designing, coding, testing and providing support for applications. Will handles custom applications and the KTL suite of products. He has worked in the GP channel for over 15 years on integration and customization to Microsoft Dynamics. Will has extensive knowledge of Visual Basic, Visual Basic for Applications, MS SQL Server T-SQL, Crystal Reports and SQL Reporting Services. Will also works with the Microsoft .Net framework, including WPF, Web Services, Desktop Applications and Web Application development.