Some time ago, the question
why events are not always equal to themselves was discussed in this forum. Actually the same is true for groups and tracks, as the compare operator only compares references, not contents. The workaround of comparing an events position in its track and an events track-ID is only useful as long as events are not moved around.
Maybe I found another workaround, but this should only be used temporarely, until Sony provides us with a real solution; also, I cannot guarantee it is always working (it seems to work for now though, using collections as well as after having moved around events), maybe Sony can give more info about this: TrackEvent objects as well as TrackEventGroup objects carry internal properties called "myEventID" and "mygroupID". I think these properties remain unchanged when events are moved around, events added to groups, and - most importantly - objects copied into collections within scripts. Unfortunately these properties are neither documented nor publicly accessible (tagged internal/private).But it is still possible to read these fields using reflection. The following code shows how it can be done - all you need to do is to copy the "ID" class into your scripts and use it the way as shown in the main loop below the class definition:
When you store these IDs, note the different types "long" and "uint" - I have no idea why the event IDs are "long"; in my case, event IDs are in the range "3458764513820540931" (but it seems only the last 4 digits change from project to project), while groupIDs are in a much more reasonable range (47, 48, etc).
Again, Sony probably doesn't want us to use this approach, and it should be done with care (no guarantee it will work in future versions etc), but it is the only workaround I can think of for now for this problem... except maybe marking an event in its Name field (which isn't documented either though). In any way it is interesting to explore such hidden features *g*
why events are not always equal to themselves was discussed in this forum. Actually the same is true for groups and tracks, as the compare operator only compares references, not contents. The workaround of comparing an events position in its track and an events track-ID is only useful as long as events are not moved around.
Maybe I found another workaround, but this should only be used temporarely, until Sony provides us with a real solution; also, I cannot guarantee it is always working (it seems to work for now though, using collections as well as after having moved around events), maybe Sony can give more info about this: TrackEvent objects as well as TrackEventGroup objects carry internal properties called "myEventID" and "mygroupID". I think these properties remain unchanged when events are moved around, events added to groups, and - most importantly - objects copied into collections within scripts. Unfortunately these properties are neither documented nor publicly accessible (tagged internal/private).But it is still possible to read these fields using reflection. The following code shows how it can be done - all you need to do is to copy the "ID" class into your scripts and use it the way as shown in the main loop below the class definition:
import System;
import System.Reflection;
import Sony.Vegas;
import System.Windows.Forms;
import System.Collections;
// Copy this class into your script, and make sure you import
// System.Reflection!
class ID
{
static var eventInfo:FieldInfo = null;
static var groupInfo:FieldInfo = null;
static function getInfo(o:Object, s:String):FieldInfo
{
var info:FieldInfo = o.GetType().GetField(s,
BindingFlags.NonPublic|BindingFlags.Instance|BindingFlags.Public);
if (info==null)
throw("Can't find "+s+" in "+o);
return info;
}
static function evnt(e:TrackEvent):long
{
if (eventInfo==null) eventInfo=getInfo(e,"myEventID");
return(eventInfo.GetValue(e));
}
static function grp(g:TrackEventGroup):uint
{
if (groupInfo==null) groupInfo=getInfo(g,"myGroupID");
return(groupInfo.GetValue(g));
}
}
// Demonstration of how to use the ID class; events/groups that return
// the same ID are probably the same events/groups:
try{
for (var trk in Vegas.Project.Tracks)
for (var e in trk.Events)
MessageBox.Show(e.ActiveTake.Name+", ID:"+ ID.evnt(e) +
", IsGrouped="+e.IsGrouped+", groupID: "+ID.grp(e.Group));
var q:Queue = new Queue();
for (var trk in Vegas.Project.Tracks)
for (var e in trk.Events)
q.Enqueue(e);
for (var e in q)
MessageBox.Show(e.ActiveTake.Name+", ID:"+ ID.evnt(e) +
", IsGrouped="+e.IsGrouped+", groupID: "+ID.grp(e.Group));
} catch(e) {MessageBox.Show(e);}
When you store these IDs, note the different types "long" and "uint" - I have no idea why the event IDs are "long"; in my case, event IDs are in the range "3458764513820540931" (but it seems only the last 4 digits change from project to project), while groupIDs are in a much more reasonable range (47, 48, etc).
Again, Sony probably doesn't want us to use this approach, and it should be done with care (no guarantee it will work in future versions etc), but it is the only workaround I can think of for now for this problem... except maybe marking an event in its Name field (which isn't documented either though). In any way it is interesting to explore such hidden features *g*