Comments

roger_74 wrote on 9/23/2003, 3:08 AM
var filepath : string = this.ScriptFile;

or

import System.IO;

var path : string = System.IO.Path.GetDirectoryName(this.ScriptFile);

for the path without the file
jetdv wrote on 9/23/2003, 8:45 AM
It can be simplified to:

var mypath = Path.GetDirectoryName(ScriptFile)

but you do need the proper imports set (i.e. import System.IO)
roger_74 wrote on 9/23/2003, 4:56 PM
That's a funny thing. Sometimes I have to use the System.IO namespace for the Path functions even though I use import System.IO, and sometimes I don't. Maybe it's because I usually have my own assemblies in my scripts.

Whether you use var mypath or var mypath : string is a matter of taste i guess. But it's not a bad habit to have when things get bigger and more complicated.
rcampbel wrote on 9/25/2003, 9:32 AM
Great! Thanks.

Randall
SonyPJM wrote on 9/25/2003, 10:28 AM
roger_74 wrote:

> Whether you use var mypath or var mypath : string is a matter of taste
> i guess. But it's not a bad habit to have when things get bigger and
> more complicated.

I am indeed finding that it is usually best to strongly type variables in your
scripts using the "var name : type" syntax in JScript and
"Dim name As type" in VB... especially when the scripts get big
and complicated. This helps eliminate bugs and, although it is
usually not noticeable, it helps scripts run a bit faster.

The bugs come up when there are ambiguities as to how the script
interpreter should cast a typeless (variant) variable. For example,
consider this code:



var typelessVar = 10000.0;

var startTime = new Timecode(typelessVar);


Since there are multiple Timecode constructors with a single argument,
the script interpreter may choose the one that takes a String and
coerce typelessVar by essentially calling its ToString() method. But
most likely the code is meant to use the Timecode constructor that
takes a double.

In Vegas 5, this example will become even more likely to produce
errors because another single argument Timecode constructor will
likely be made public which takes an Int64. This constructor is
useful because it allows scripts to work with Timecodes in the exact
units that their underlying representation uses... 100 nanosecond
units.