| IC3 Scripting and Automation | |
|
| English | 日本語 (Japanese) |
ScalaScript describes pages, elements, actions, and events in Scala. Click here for IC3 ScalaScript Syntax documentation.
The Windows Script EX lets you extend playback behavior by connecting a ScalaScript to additional code you create in your favorite scripting language. This can be used for advanced control and customization, data integration, etc.
The Windows Script EX lets you use any Windows Script Host compatible language, including:
There are Windows Script Host compatible versions of other languages, including Perl, Ruby, TCL, and REXX.
Various examples of using Windows Script in Scala, and other advanced scripting features of Scala, can be found here, or on the Scala Support CD.
To run a Windows script is run from a ScalaScript, add a WindowsScript event to the ScalaScript. You choose the Windows script file, the scripting engine (language) to use, and whether the ScalaScript should wait for the Windows script to complete. In addition, you can choose to share one or more ScalaScript variables for access from the Windows script.
In the Windows Script EX, you can select one or more ScalaScript variables to share with the Windows Script. These variables then become available as objects you can use in the Windows script, where you can read them or change them. If you change a variable from within the Windows script, it changes live in Scala. Shared variables can be used to pass data in either direction between ScalaScript and a Windows script.
Here is a VBScript example. This assumes you have shared a variable called sharedvariable.
In truth, the shared variable is actually a Windows script object, whose value is represented by the .Value method. This is the default method in VBScript, so the above works without explicitly writing out .Value. However, in JScript and other languages, you have to explicitly use the .Value method to get at its value. Here is a JScript example:
ScalaScript supports array variables, as do Windows Script languages. When you share a ScalaScript array variable, the variable on the Windows Script side is a Collection object of variable objects. In VBScript this is easy, however for arrays you must explicitly use .Value when writing to a shared array variable. In this VBScript example, .Value is shown explicitly when reading too, for consistency:
For languages other than VBScript, you have to explicitly use the .Item(n) method to access the nth entry of the array, then the .Value method to get at its value. Here is a JScript example:
A Windows script starts when the Window Script EX event is encountered in playback. There are various ways to synchronize the Windows script to the ScalaScript. Many of these techniques are illustrated in the advanced scripting examples.
The simplest form of synchronization is to run the Windows script with the Wait option set to on. The Windows script will run to completion before the ScalaScript resumes.
Alternatively, the Windows script can be free-running, launched with Wait off, and no particular synchronization. Any shared variables that are changed by the Windows script will be reflected live in the ScalaScript.
Both the Windows script and the ScalaScript can periodically check for a change in the value of a shared variable, then sleep for a fraction of a second.
The TextCrawl and GlobalTextCrawl elements support a cued expression with a cue control variable. The Windows script side uses polling synchronization, but the ScalaScript side uses the cue control variable to coordinate the feeding of new text from the Windows script into the crawl.
In ScalaScript, the OnNotification command lets you monitor a shared variable, and trigger a Goto or Use when that variable changes.
The ScalaPlayer interface is the basic support interface exposed to a Windows script when run from the Windows Script EX. To create a handle to this interface, do as follows:
The ScalaPlayer interface supports the following methods:
To sleep for a designated number of milliseconds n, say:
To log a message to IC.log, say:
The ScriptDir property returns the name of the folder containing the Windows Script.
Scala uses normal Windows paths, but it also supports a few special locations. The most important one is Content:, which is the Linked Content location. For example, if you use NetManager's Send Content job to send blah.txt to a player, that file will end up in the Linked Content location, and the Scala path would be Content:\blah.txt. However, only Scala automatically understands this extended file-path syntax. To use Windows script functions to access files inside the Content: location, you need both to resolve the file name and lock the file.
By resolve we mean convert to a normal Windows-style path, e.g.:
By lock we mean ensure that the file doesn't change out from underneath you if a new revision of the same file arrives while you're looking at it.
The ScalaFileLock interface supports the following methods:
Note that if a new revision of a file arrives while you have one revision already locked, the new revision is still installed, and will be given to you the next time you inquire, all without disturbing the current revision.
Example:
The ScalaIntegration DLL provides methods to support Windows scripts or custom applications that need to create, deliver, or install media files in a way which allows them to be seamlessly introduced into a Scala script.
When a Scala script references linked content, that content is not included when the script is published, but is expected to be found on the player at run-time. One way to get that content to the player is to send it using NetManager's Send Content job command.
If instead you want to use a custom application to fetch or create the linked content, then the ScalaIntegration DLL helps you deposit the file correctly into the InstalledContent folder, and prevents access collisions with the Scala script which may simultaneously be accessing the file. Examples of such applications include:
ScalaIntegration and Player cooperate so that if Player is currently reading a file, ScalaIntegration can install a new version of that file that will be used the next time player needs that file. Likewise, if ScalaIntegration is part-way done installing a file when Player needs it, Player gets the most recent fully-installed copy.
This DLL is installed as part of the IC3 Player installation and provides an API to accomplish seamless file installation. To use it from Visual Basic or VBScript first you must instantiate the ScalaIntegration.FileInstaller interface:
The most important thing you can do is install a file (in this example, "C:\MyStuff\MyFolder\foo.txt") to the InstalledContent folder. Typically you would generate or download the file to some location you manage, then use the following technique to move the file to the InstalledContent folder.
When installing new content, the player will automatically use that new content the next time around. For example, if installing a new JPEG, that new image would be used for the next clip or background that references it. When installing a new script, it would be used the next time the script is referenced.
There are InstallToContentFolder() and GetMediaContentFolder methods, but these are no longer recommended — files not sent from NetManager belong in the InstalledContent folder and the above technique should be used.
As discussed above, newly installed content is used the next time it is referenced. In some cases, this could mean the new content is not used until a script loops, for example. To force an immediate restart of playback, use the RestartPlayback methods.
To restart the player engine, use:
This method returns True if it succeeds, or False if it fails. You can pass in optional arguments that will return the error number and an error description string if this method fails.
The InfoChannel Publish Server is a feature that is installed with InfoChannel Designer 3 to support external applications that wish to represent and publish content to an InfoChannel network. The Publish Server:
To use the Publish Server, install InfoChannel Designer 3, and connect a valid Designer or NetManager dongle. To start the Publish Server, run the PubServer.exe application from Designer's program folder. When running, the Publish Server places a Scala exclamation point logo in the system tray, to indicate that the server is running. To stop the server, right-click on the exclamation point and select Stop InfoChannel Publish Server.
When the Publisher Server is running, it offers a COM interface to access its Publish to InfoChannel Network and Generate Thumbnail features. This COM interface can be accessed from VBScript or many other languages. It contains these methods:
Where:
GoPublish asynchronously initiates a publish operation. Multiple operations can be queued. Once initiated, you can check the progress of a publish operation by passing the handle returned from GoPublish to the CheckPublish method. See the CheckPublish method for more information and a full VBScript example on how to invoke both methods.
Where:
CheckPublish (available in Release 7.3.1) synchronously requests progress information on a publish operation in progress. It may be called repeatedly to request information on a handle returned from GoPublish. A publish operation has ended when out_currentscriptnum > out_numberofscripts.
An example VBScript might look like this:
GenerateThumbnail synchronously generates a thumbnail of either the specified page or the first page of the provided script file. The thumbnailfilename parameter must contain the full path plus the filename and the extension of the desired image. The resulting image can be in .jpg, .bmp, .gif, or .png format, based on the file extension the caller supplies.
An example VBScript invocation might look like this:
