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: [email protected]
[mailto:[email protected]] 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
<[email protected]<mailto:[email protected]>> 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:
[email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Eric Thivierge
Sent: Friday, November 30, 2012 2:18 PM
To: [email protected]<mailto:[email protected]>
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
<[email protected]<mailto:[email protected]>> wrote:
