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 );