#GPPT Converting .Net Execute Scripts from C# to VB.Net

Following on from the previous articles: #GPPT Speeding Up Referencing Modifier Added Fields and staying Web Client compatible and #GPPT Referencing Modifier Added Fields in the Web Client using .Net Execute, this article looks how we can use VB.Net rather than C# as the scripting language in the .Net Execute scripts.

Both VB.Net and C# use the .Net Common Language Runtime (CLR) and it is usually possible to write exactly the same code in either language. So we will duplicate our existing C# scripts and convert them to VB.Net, then we will duplicate the triggers to call the new scripts.

#GPPT Speeding Up Referencing Modifier Added Fields and staying Web Client compatible

Using the method discussed in the article #GPPT Referencing Modifier Added Fields in the Web Client using .Net Execute it was possible able to get past some of the limitations mentioned in the article Dynamics.Application Object not available on Web Client.

However, running the .Net (C# or VB.Net) code is slightly slower than running the Dexterity (sanScript) code. This article explains a method of how to improve Desktop Client performance while staying compatible with the Web Client.

#GPPT Referencing Modifier Added Fields in the Web Client using .Net Execute

You probably saw the recent article: Dynamics.Application Object not available on Web Client where I described an issue that was recently discovered and meant that the “Continuum” based triggers and scripts used to reference Modifier Added Fields in GP Power Tools – Developer Tools module were unable to work in the Web Client.

I mentioned a workaround that would function with the current GP Power Tools code when running on the Web Client (and Desktop Client). This article will show how you can use scripts in the .Net Execute Setup window to reference Modifier Added Fields.

#GPPT Disabling Manual Entry of SOP Number Field

Recently on the GPUG Open Forum, Jeff Roe asked if it was possible to disable manual entry by users into the SOP Number field on the Sales Transaction Entry (SOP_Entry) window.

I suggested using GP Power Tools – Developer Tools module to create a quick trigger to lock or disable the field. As Jeff is already a GP Power Tools user and has the Developer Tools module registered, I created the required code and posted it on the forum thread. Here is a slightly more detailed version of the forum response.

#GPPT Reporting for Minnesota’s Wage Theft Law

This article is comes about thanks to my friend, Melissa Brown, who approached me for a solution to a reporting requirement she had for a customer due to new legislation brought in by the US state of Minnesota.

The requirement was not possible to solve with the Dynamics Report Writer alone as it involved an array in a table which prevented a static relationship from working to retrieve the data needed.

#GPPT Dexterity Samples for Datatype Conversions

The previous article: #GPPT Parsing Returned SQL Data into Rows and Columns had some examples of how to convert string representations of various datatypes back to their native datatypes.

With GP Power Tools, it is a common technique to store additional data in the DUOS (Dynamic User Object Store) table (SY90000). However, the DUOS uses a 132 character string field to store the data and so datatype conversions in both directions will be needed.

#GPPT Parsing Returned SQL Data into Rows and Columns

When writing customizations using GP Power Tools as your development tool, there may be times where you need to return a SQL query as a data set to your Trigger Setup script or Runtime Execute Setup script.

It is possible to display a data set to the end user in a SQL Results window using the MBS_SQL_Results helper function. If you have “Goto” actions defined, the MBS_SQL_Results_Goto helper function will display the data and enable the SQL Goto functionality.

But what if we don’t want the data displayed to the user and just need to use the data in your code.