OpenSpan is, of course, built on Microsoft’s .NET framework. That fact leads to all sorts of interesting possibilities.
The simplest being you can create a Script block in your automation and write a method in C# or VB.NET. These are great when you want to make a System call, or when you’ve got some hairy logic, that would take a lot of Comparison blocks and connectors in your automation.
Script blocks are found under the OpenSpan Advanced tab in the Toolbox window. After dragging into your automation, set the scope to “Global” (Better yet create it in a Global Container.) if you want to use the script in more than one automation.
You need to keep the code simple, because other than making sure the script code compiles without errors, you don’t get any Intellisense or debugging help in there. To make absolutely sure my script behaves as expected, I sometimes have resorted to writing the script inside a VS Console Application project so I can call it and step through it with the debugger. When I’m satisfied, I cut and paste the code into the script block. This begs the question though; How do you test it again, if you need to modify the script in the future? I’m afraid I don’t have a good answer for that. Good SW development practice would dictate that there is only one source for the code, so you would need to keep the Tester Console Application project under source control, and only modify that, and only copy and paste into the Script block, never just modify the script itself. I must confess though that I have thrown the Tester Console Application away when I’m done with initial development, and trusting that any future changes to the script, will be small enough to be done in place.
You’re not limited to just passing in strings, integers, floats, or bools into the script, you know. All of the OpenSpan controls are just .NET object types and may be passed as parameters into a script also. Check out this script:
Let’s make that code a little easier to read:
We pass a parameter of type “object” into the script and return a string corresponding to the object’s type. Here is the the script called in an automation, “q” being the text box, on Google’s home page.
So why would you want to do this? If you had to do the same thing to a bunch of different controls, for instance, you could write a script to do it for you, and you would simply pass each control into the script. What methods and parameters are available to use on the control passed into the script? Well you have a list of Parameters and Methods in
Of course, we can do the same thing with an automation. Create an Entry Point to an automation pull down the parameter types list, and click “Browse”, to pick a data type other that String, Boolean, Integer, or Float,