One reason why many people overlook the scripting feature is that it is opt-in. For security reasons, we decided to default the availability to false. Switching it on is just a matter of setting the option LL_OPTION_SCRIPTENGINE_ENABLED (index 276) to 1. Let’s do a quick walkthrough, using the “order list with scripting” sample report of the demo application. It displays the order number, order and delivery date and a script-powered calculation of the number of working days between those two dates.
The last column in the report just reads:
ScriptVal ("CSharpScript", LoadFile$ (ProjectPath$() + "WorkingDays.cs"))
That means, load the WorkingDays.cs script from within the project path and return its value. So let’s dig into the script. The crucial part is the Main() method:
static void Main() { var workDayCalc = new WorkingDaysCalculator(); WScript.Result = workDayCalc.Calculate(Report.Field("Orders.OrderDate"), Report.Field("Orders.ShippedDate")); }
The WorkingDaysCalculator is just a simple class to calculate the working days in a quite simple manner. The more interesting part is the usage of the Report object that’s added dynamically. It has a couple of methods:
Method name | Purpose |
---|---|
Eval | Evaluates a full List & Label formula, based on the provided fields and variables at the time of evaluation |
Variable | Gets the value of a variable |
Field | Gets the value of a field |
SetVar | Sets a variable in the report that can later be retrieved by using GetVar() outside of the script |
GetVar | Gets a variable from the report that was set earlier by using SetVar() outside of the script |
Using these methods, you can easily interact with the report and your data. And by setting WScript.Result, you can return a value for the ScriptVal function as shown above.
Additionally, there is also the possibility of debugging your scripts. All you have to do is add the line
<!--#pragma debugmode-->
at the very beginning of the script. This will automatically include the following code at the start of the Main() method
System.Diagnostics.Debugger.Launch(); if (System.Diagnostics.Debugger.IsAttached) { System.Diagnostics.Debugger.Break(); }
which will start a suitable debugger (if there is one installed on your system), attach it to the LL process, and break before any of the actual code gets executed.
Looking forward to seeing more usage of this hidden gem in the future :-).