Scripting using C#
With version 3.04.04, more support was added for C# Scripting in finPOWER Connect.
Overview
Historically, Intersoft has used Visual Basic as the programming language for our built-in and sample Scripts.
C# has always been an option in many parts of the system (Scripts, Documents etc) however, the focus, until now, has always been on using Visual Basic.
Previously, not all areas of the system supported C#. In 3.04.04, we have added support and enhancements for C# in the following places:
- Portals
- Account Application Types
- Summary Page Standard Block Override (some function definitions were not compatible with C#)
C# Compatibility with Visual Basic
The syntax difference between C# and Visual Basic will not be much of a barrier for most programmers however, because the business layer has its roots in Visual Basic, using certain functionality may not be particularly intuitive.
Global Collections
From Visual Basic, you can access collections such as Documents
using the record Id, e.g.:
finBL.DebugPrint(finBL.Documents("AL").Description)
When using C#, you must use the array syntax instead:
finBL.DebugPrint(finBL.Documents["AL"].Description);
Implicitly, both of the above examples are calling the Item
method of the finBL.Documents
collection.
Another way to access global collections such as this is to use the ItemByPk
property, e.g.:
finBL.DebugPrint(finBL.Documents.ItemByPk(1).Description)
C# however does not understand properties that take parameters. If we were rewriting the business layer today, properties such as this would be defined as methods and would therefore be simple to use in C#. However, this is not the case so we must use a special syntax to read this property in C#:
finBL.DebugPrint(finBL.Documents.get_ItemByPk(1).Description);
NOTE: For every property that receives parameters in Visual Basic, .NET generates a get_
version and, if the property can also be written to, a set_
version. Unfortunately, these do not currently appear in the Script Editor's member dropdown for C#.
Dates
Where Visual Basic code tends to use the Date
variable type, C# uses DateTime
.
Certain parts of the finPOWER Connect business layer have optional date parameters, e.g., the following Summary Page Standard Block:
Public Overrides Function BankingDetails_Summary2(callerScriptInfo As ISScriptExecutionInfo,
bankingDetails As finBankingDetails,
Optional account As finAccount = Nothing,
Optional dateAsAt As Date = Nothing,
Optional includeWarnings As Boolean = True,
Optional includeActions As Boolean = True,
Optional otherParameters As ISKeyValueList = Nothing) As ISSummaryTables
Dim SummaryTables As ISSummaryTables
SummaryTables = MyBase.BankingDetails_Summary2(callerScriptInfo, bankingDetails, account, dateAsAt,
includeWarnings, includeActions, otherParameters)
Return SummaryTables
End Function
In Visual Basic, optional dates are defined as Date = Nothing
. In C#, we need to use the special syntax default(DateTime)
, e.g.:
public override ISSummaryTables BankingDetails_Summary2(ISScriptExecutionInfo callerScriptInfo,
finBankingDetails bankingDetails,
finAccount account = null,
DateTime dateAsAt = default(DateTime),
bool includeWarnings = true,
bool includeActions = true,
ISKeyValueList otherParameters = null) {
ISSummaryTables SummaryTables;
SummaryTables = base.BankingDetails_Summary2(callerScriptInfo, bankingDetails, account, dateAsAt,
includeWarnings, includeActions, otherParameters);
return SummaryTables;
}
Type Casting
The syntax for type casting in Visual Basic is quite different to C#.
The following example is typical of the "Finish" event in many HTML Widgets in Visual Basic:
' Parse Parameters
If finBL.Runtime.WebUtilities.DeserialiseJsonStringToObject(parametersJson, GetType(FormInitialisationInfo), obj) Then
Record = DirectCast(obj, FormInitialisationInfo)
Else
Success = False
End If
The C# syntax is a little different:
// Parse Parameters
if (finBL.Runtime.WebUtilities.DeserialiseJsonStringToObject(parametersJson, typeof(FormInitialisationInfo), ref obj)) {
Record = (FormInitialisationInfo) obj;
}
else {
Success = false;
}
Unassigned ByRef Variables
Often, in Visual Basic, a business layer method receives a ByRef
(ref
in C#) variable, e.g.:
Dim AccountId As String
If finBL.AccountFunctions.GetAccountIdFromExternalId("X10000", accountId) Then
End
In C#, you need to initialise the variable before it is passed:
String AccountId = ""
if (finBL.AccountFunctions.GetAccountIdFromExternalId("X10000", ref accountId)) {
}
Business Layer Incompatibility with C#
The business layer has many functions and methods that may be difficult to use or even impossible to use in C#.
When notified of these issues, we will look at adding C# compatible functionality to the business layer.
Conclusion
Better support for C# has been one of the main focuses for version 3.04.04.
For example, in version 3.04.04, the methods finAccount.GetUserDataByIndex(2)
and finAccount.SetUserDataByIndex(2)
can be used by either Visual Basic or C# code as an alternative to finAccount.User(2)
which is a parameterised property and therefore not intuitive to use in C# Scripts (finAccount.get_User(2)
and finAccount.set_User(2)
) and also not available as intellisense in the Script editor.
Future versions are likely to enhance support further, and it is likely that some upcoming HTML Widgets will use C# instead of Visual Basic (if for no other reason than to serve as examples for programmers more comfortable using C#).
The following Knowledge Base articles relate to C# functionality: