The whole point of using the self-installing custom properties is you can build 
a more robust and reliable toolset around them.

One issue encountered with using tools to work with custom properties is 
figuring out what custom property you have so your tool knows what it should 
do.  If you query a custom property created  using the Animate > Parameter menu 
using the SDK, it will always return 'customparamset' as it's type which means 
you are relying on the name as the identifying key.  If you use a self 
installing custom property, it will report the plugin name as its 'Type' which 
is fixed and does not change.

Example:

                // CustomParamSet
var oCustomParamSet = ActiveSceneRoot.AddProperty( "Custom_parameter_list", 
false, "joe" );
LogMessage( "Name: " + oCustomParamSet.Name );
LogMessage( " Type: " + oCustomParamSet.Type );
LogMessage( "Class: " + Application.ClassName( oCustomParamSet ) );

                // Self installing custom property
                Var oCustomProperty = ActiveSceneRoot.AddProperty( "TextProp", 
false );
                LogMessage( "Name: " + oCustomProperty.Name );
                LogMessage( "Type: " + oCustomProperty.Type );
                LogMessage( "Class: " + Application.ClassName( oCustomProperty 
) );


The importance here is when you want to write queries and selection filters.  
With a self installing custom property you can isolate specific custom 
properties to make your tools more reliable and robust by filtering by the 
custom property's "Type".  Useful after you've made a call to FindObjects() and 
need to whittle the result list down a bit further for your purposes.  In the 
event you want to update the custom property's parameter list or make other 
changes, the self installing plugin has version information which can be 
leveraged to target which properties need to receive the updates when a scene 
or model is loaded.   You you no such information available with 
customparamsets which means you are running blind.

Example:

var oCustomProperties = FindObjects( "", CLSID_CUSTOMPROPERTIES );

// find only CustomProperties of type "Text Prop" in the results
var oFilteredCustomProperties = oCustomProperties.Filter( "TextProp" );

This is especially useful when using the "Collection" argument handler in self 
installing commands as Softimage will replace empty arguments of this type with 
the current selection in the scene.  If your code is expecting a collection of 
custom properties of a specific type, you can use the .Filter() method to 
quickly validate the incoming data and minimize surprises downstream.

With customparamsets you must iterate through the collection and filter it 
manually which can be expensive on large scenes and not terribly reliable:

                Var oCustomProperties = FindObjects( "", CLSID_CUSTOMPROPERTIES 
);

                for ( var i = 0; i < oCustomProperties.Count; i++ ) {

                                var oCustomProperty = oCustomProperties(i);

                                If ( oCustomProperty.Type == "CustomParamSet" ) 
{
                                                // it's a 
customparamset...that's all we know so far.
                                                // Must check the 
customparamset's name and hope it hasn't been mangled or renamed by user.
                                                If ( oCustomProperty.Name == 
<name> ) {
                                                                // must employ 
additional logic in  case multiple properties exist in the scene of various 
versions
                                                                If ( 
oCustomProperty.Parameters.Count == <some known number> ) {
                                                                                
// we *might* have what we want.
}
                                                }
                                }
                }



Artists left to their own measures would not be expected to use self installing 
custom properties, but for those looking to save time and energy, it's a smart 
way to work and doesn't require much in the way of learning.


Matt




From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Alan Fregtman
Sent: Saturday, December 01, 2012 5:07 PM
To: XSI Mailing List
Subject: Re: reorder custom parameters

I'm still a big fan of this plugin to do logicless layouts: 
http://www.softimageblog.com/archives/172

Yea, it needs a plugin, but with the one plugin you can have all the custom 
paramset layouts you want! (No logic though.)

On Fri, Nov 30, 2012 at 5:23 PM, Matt Lind 
<ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
I'm not suggesting people use custom properties as one-off applications.

With the addition of workgroups to make installation a drag and drop operation 
and the benefits self installing custom properties provide, there's really no 
reason why they shouldn't be used and preferred over customparamsets.  
Customparamsets were the original custom property and only exist in their 
current form because there wasn't a formal SDK or architecture to support what 
self installing plugins can now do.

Matt




From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 
[mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>]
 On Behalf Of Eric Thivierge
Sent: Friday, November 30, 2012 2:18 PM

To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: reorder custom parameters

Well as you say it may function properly but if errors are logged and people 
see that every time an asset is loaded, in my experience, it tends to ensure 
your artists get annoyed by the constant / repeated errors every time they load 
a scene / asset. May give them the false impression that someone doesn't know 
how to fix / deal with the issue. They may also tend to ignore actual error 
messages too because they are used to ignoring them. To each their own as it 
goes.

--------------------------------------------
Eric Thivierge
http://www.ethivierge.com
On Sat, Dec 1, 2012 at 8:48 AM, Matt Lind 
<ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:



Reply via email to