Referencing TestStand objects as Containers...

[Bob Rafuse]

If I reference TestStand objects using the RunState container, I can
directly access the object properties in a TestStand Statement step
because TestStand apparently has converted these objects into
Containers. Using a SequenceFile reference as an example, if I
reference either:

RunState.SequenceFile or
RunState.InitialSelection.SelectedFile

in a Statement, I can then access SequenceFile properties of these
objects step simply by appending the subproperty paths, like:

RunState.SequenceFile.Data.Seq[0].Parameters... etc.

I can also pass this SequenceFile object around to other Sequences by
defining a Parameter of type Container and passing the SequenceFile
reference.

My question is, if I load a SequenceFile using the
Engine.GetSequenceFileEx method (or any other method of loading a
sequence file programatically), is there a way to reference this
SequenceFile object in a similar manner (as a Container)?

I have a whole suite of TestStand sequences that initially worked off
of "RunState.InitialSelection.SelectedFile" and passed this
SequenceFile Container around. I was hoping to adapt these seqeunces
to work with other SeqenceFiles loaded with GetSequenceFileEx (or some
other method if necessary) without having to convert everything over
to using Object References and explicitly accessing Property Objects.
Essentially, I'm looking for a way to load TestStand objects as
Containers or reference TestStand objects through Containers, similar
to to how TestStand references them using RunState. Is this at all
possible?

---
Bob

[Scott_Richardson]

Bob -
Some key issues to better understand are the following:
1) Almost all COM objects in TestStand derive from the PropertyObject interface. We did this so that internals of an object, like a SequenceFile, can store information in a tree structure and that tree structure can be explored. It also allows us to easily persist objects into a stream or to disk.

2) When you pass a reference as a parameter, it is an IUnknown COM pointer. A reference object does not do anything special to understand what it is, so it does not know it is a sequence file.

3) The PropertyObject interface has an alias feature and this is what the context uses to display items like RunState.SequenceFile.

To create an alias object to an object that is derived from PropertyObject, you must use an ActiveX call, specifically:
Locals.MyAliasContainer.SetPropertyObject("", PropOption_NotOwning, Parameters.RefObj)
This replaces "Locals.MyAliasContainer" with the container that "Parameters.RefObj" references.

Take a look at the online help for PropertyObject.IsAliasObject for a little more information on aliases.

[Bob Rafuse]

Scott,

Thanks. This is just what I was looking for...

---
Bob

"Scott Richardson (NI)" <x@no.email> wrote in message
news:167484@exchange.ni.com...
Bob -<br>Some key issues to better understand are the following:<br>1)
Almost all COM objects in TestStand derive from the PropertyObject
interface. We did this so that internals of an object, like a
SequenceFile, can store information in a tree structure and that tree
structure can be explored. It also allows us to easily persist
objects into a stream or to disk.<br><br>2) When you pass a reference
as a parameter, it is an IUnknown COM pointer A reference object does
not do anything special to understand what it is, so it does not know
it is a sequence file.<br><br>3) The PropertyObject interface has an
alias feature and this is what the context uses to display items like
RunState.SequenceFile.<br><br>To create an alias object to an object
that is derived from PropertyObject, you must use an ActiveX call,
specifically:<br> Locals.MyAliasContainer.SetPropertyObject("",
PropOption_NotOwning, Parameters.RefObj)<br>This replaces
"Locals.MyAliasContainer" with the container that "Parameters.RefObj"
references. <br><br>Take a look at the online help for
PropertyObject.IsAliasObject for a little more information on aliases.