Announcements
Attention for Customers without Multi-Factor Authentication or Single Sign-On - OTP Verification rolls out April 2025. Read all about it here.
WCrihfield
in reply to: maxim.teleguz

Not only is this an old conversation, but it already had two decent answers, and your post is a little off topic here.

The main question was how to add a custom iProperty as a Date type iProperty, and/or how to change an existing Text type iProperty to a Date type iProperty.  We have already demonstrated above that in order to create a Date type iProperty, you must set a Date type Value to it when you create it (not just a String that looks like it contains text formatted to look like a Date).  The missing bit of information here is that you can simply change a Text type iProperty over to a Date type iProperty, by simply changing its Value, as long as the new Value is of Date Data Type.

For example, even if I created a Text type iProperty using the iProperties dialog Custom tab like this:

WCrihfield_0-1649435494898.png

Then, if I simply want to change it's type from Text to Date by using an iLogic rule and the iProperties.Value() iLogic snippet, I can do so like this:

iProperties.Value("Custom", "Test1") = Now

Then when you look at that custom iProperty in the iProperties dialog, custom tab again, you can see that its Type setting has changed from Text to Date, and you can see that the new Value is an actual Date like this:

WCrihfield_1-1649435711299.png

And just in case you may not have known, if the custom iProperty does not already exist, then when you use that iProperties.Value() snippet to set the properties Value, it will automatically create the custom iProperty for you.  The same is not true if you are just trying to read the current value of an iProperty though.  If it does not exist, it will throw an error.

 

There are two main ways to avoid the error in a situation where the iProperty might not already exist and you want to try to get its value.  The most logical and efficient first choice should usually be to use a loop of the custom PropertySet to find the ones you are looking for.  Then if they were not found, create them.  None of that usually requires any special error handling.  That may (or may not) require slightly more code that using a Try...Catch block route, so it may (or may not) take a little longer to write the code.  The second fall back option and less efficient way, which may seem like a shortcut for the coder, would be to use the Try...Catch block.  In small, simple projects, there may be very little difference in performance, but in larger, more complex projects, the Loop and If...Then statements will generally result in better performance.

 

Wesley Crihfield

EESignature

(Not an Autodesk Employee)