Custom PPG's do not work with Multi Selection?

[Bradley Gabe]

I've noticed this before, and now it's happening with a custom tool kit I've been developing.

I have a simple Custom PPG defined in a self installing plugin and am applying it to multiple objects in the scene. However, if I multi-select the objects, the PPG doesn't show up at the top of the selection explorer.

If I open the PPG on one of the objects, then multi select other objects with the same custom property, the title bar of the PPG reads "[multi]", but none of the multi selection features work... if I edit a parameter, it only affects the first item in the selection.

What gives? Is there a way to construct the PPG in order to avoid this behavior? I really need them to work in multi-selection mode!

-B

[Dan Yargici]

I've seen this many times too and would also love to know the reason!

Eagerly awaiting any info...

DAN

[Bradley Gabe]

I'm not sure if this is what is causing it for other scenarios, but I've figured out what was causing it for me.

I have a script that is doling these Properties out onto scene objects, but it is also changing their names to something different than the registered PPG name:

SceneObject.AddProperty("MyCustomProp", 0, "DifferentName")

Even though all of the SceneObjects get a custom prop with the same exact name, XSI treats them as if they are unique and doesn't give them Multi Selection super powers.

If instead I leave out the 3rd Parameter in AddProperty:

SceneObject.AddProperty("MyCustomProp", 0)

I get appropriate PPG behavior with Multi Selection.

[Matt Lind]

I don’t know if this is the same problem we ran into many years ago, but it goes something like this:

 

To the best as I could figure out, the problem mostly appears when you have defined more than one RGBA color parameter (4 parameters of type siFloat) into a RGBA color widget.  Any parameters defined in the custom property after that point will not respond to multi-selection behaviors.  My workaround was to put the color parameters last in the custom property’s _Definition() callback. 

 

The 2^nd part of the workaround is how you read parameters inside of a callback.  Softimage does have a few bugs here or there that I found many years ago and reported, but as far as I could tell they were fixed in 2012 SP1.  Anyway, how you pull parameters inside the callback is important.

 

Example:  The typical syntax to get access to a custom property and it’s parameters from inside an _OnClicked() or _OnChanged() parameter callback is something like this (Jscript):

 

Parameter_OnChanged()

{

                var oCustomProperty = PPG.Inspected.Item(0);

                var oParameters = oCustomProperty.Parameters;

 

                var ParameterValue = oParameters( “parametername” ).value;

                …

}

 

The key part of the whole equation is the first line.  In this example it pulls the first custom property in the inspected list.  If you want to consider all custom properties being inspected, you must iterate through the InspectItems collection and treat them one at a time.

 

 

Matt

[Raffaele Fragapane]

Might be Matt is on the right track.
Very recently I've had some CPSets that have quite a few parameters, a layout as dynamic as it can be with PPGs, and they were applied and tweaked to quite a few different rigs and worked fine in multi at all levels, so I can't say I've seen the problem.
They are all colour widget and table free though, but include just about everything else.