This vastly extends the power of List & Label expressions, of course. As a script can introduce arbitrary security problems, this is an opt-in feature only – your application has to set a corresponding option in order to get scripting support. It’s easy:
LL.Core.LlSetOption(LlOption.ScriptingEngineEnabled, 1);
Once this option is set, you can use the Script$() function in the Designer as follows:
A more advanced application could be a script to count the number of work days between two dates – provided you have a map of public holidays, it’s simply the number of days that are not (depending where you live, of course) Saturday or Sunday or public holiday. So you simply loop through all days, check if they are in your holiday map or weekend days and – if not – increment your counter by one. This is something that would not be possible with LL’s own expression language as it doesn’t support any looping (yet 🙂 ). Also, you probably don’t want to edit such a script in the function wizard directly as it doesn’t have Autocomplete or Intellisense for C# Scripts (yet 🙂 ). The solution is simple – you just include a file that you can create in the editor of your choice. You include it by using the LoadFile$() function like
Script$("CSharpScript",LoadFile$(ProjectPath$()+"WorkingDaysSample.cs"))
By including a pragma you can even configure your favorite debugger to fire up upon script execution and debug your script using all of Visual Studio’s glory:
I’m really curious to see what you guys will do with this feature. Oh, and by the way, this was one of the highest voted suggestions in our feedback portal. You asked and we listened.
If I can use
Script$(“Powershell”, “$WScript.Result=Get-Date”)
this would be perfect. Especially when I use
Script$(“Powershell”,LoadFile$(ProjectPath$()+”WorkingDaysSample.ps1″))
So I can use Powershell ISE to check my scripts on a customer PC.
Mike
Hi Mike,Yes, Powershell would be another “dialect” that would be nice to support. However, AFAIK it’s not available in the Windows Scripting Host but rather vice versa.