Connecting up the hierarchy is a problem. It effectively bars
a user from changing anything else on the property. There isn’t a workaround, is
there?
From:
owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of
Stephen Blair
Sent: 28 September 2007 14:15
To:
XSI(at)Softimage.COM
Subject: RE: multiple, on the fly output ports,
compiled op
Hi
Kim
It is
a known problem (UDEV00235577) that
ConnectToGroup cannot connect to a parameter; instead it goes up the hierarchy
to connect.
I
don't know about the "cannot change the parameter" part, I haven't tested
that.
Steve
From:
owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of kim
aldis
Sent: Fri 28 September 2007 7:12 AM
To:
XSI(at)Softimage.COM
Subject: multiple, on the fly output ports, compiled
op
Given the following:
PortGroup oOutputPortGroup = newOp.AddPortGroup( L"Output" );
newOp.AddOutputPortByClassID( siPrimitiveID, L"Out", oOutputPortGroup.GetIndex()
);
// reserve output port
PortGroup oOutputPortGroupPoints = newOp.AddPortGroup( L"PointCountsOut" );
newOp.AddOutputPortByClassID( siParameterID, L"OutPoints",
oOutputPortGroupPoints.GetIndex()
);
// reserve output port
and given below that oKA_UVGrid is another custom operator,
why would the ConnectToGroup method connect the oKA_UVGrid property rather than
the parameter I’ve asked it to connect. And why, subsequently when I’m in the
update and get a Primitive on this port, can I not change the parameter that I
should be seeing, even if I do try connecting the primitive rather than a
parameter?
CustomOperator prop = ctxt.GetSource();
Parameter oUcount = oKA_UVGrid.GetParameter( L"Ucount" );
LONG iInst;
prop.ConnectToGroup( 1, oUcount, iInst
);