RE: multiple, on the fly output ports, compiled op

["kim aldis" <xsi(at)kim-aldis.co.uk>]

Nope, still the same.

 

Thing is, everything I’m looking at, post-application, is telling me this op is connected correctly to and output. Except when I look at the PPG where there’s no sign of a connection. Looking at the images below; am I doing something wrong or is this just busted?

 

ß this looks good.

ß should be operator connected lozenges on these parameters.

 

From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Stephen Blair
Sent: 28 September 2007 14:46
To: XSI(at)Softimage.COM
Subject: RE: multiple, on the fly output ports, compiled op

 

Maybe UpdateConnectOnOp ?

Someone suggested it to me but I never got around to trying it.

 

---

From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of kim aldis
Sent: Fri 28 September 2007 9:34 AM
To: XSI(at)Softimage.COM
Subject: RE: multiple, on the fly output ports, compiled op

OK, that’s good to know.

 

Checking the op in the sdk explorer, the connection to the oKA_UVGrid operator as an output looks good but looking at the property page of the oKA_UVGrid operator itself, nothing is showing as connected to any of the parameters. I would expect to see  operator lozenges on all the operators. And I’m getting an output of the correct type  in my update function but calling a putparametervalue on any of the parameters has no effect.

 

I also broke the rules a bit and inspected the value on a oKA_UVGrid parameter. It comes back empty.

 

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