Custom Properties using Ilogic

[gconley]

I am using ilogic to add custom iproperties to existing files as we modify them and I am stumped on how to get the custom iproperty to come in as Date instead of Text.

This is the ilogic that I have created. It adds the custom iproperty as Text and I am hoping to add it as Date.  What do I need to add or change to the ilogic that will add these properties as a Date type?

customPropertySet = ThisDoc.Document.PropertySets.Item("Inventor User Defined Properties")

Dim iprop(2) As String
iprop(1) = "Released for Construction"
iprop(2) = "Released for Review"

Try
      prop = customPropertySet.Item(iprop(1))
	  prop = customPropertySet.Item(iprop(2))
Catch
      customPropertySet.Add("", iprop(1))	  
	  customPropertySet.Add("", iprop(2))
	  
End Try

[Sergio.D.Suárez · Accepted solution]

Hi, a recommendation when working with ilogic is that even when it is not necessary to define the variables, put the variable type and define it correctly. This is a classic type of error that happens due to lack of definition of values.
Here are two methods of how I would try to solve the problem.

dim customPropertySet as inventor.PropertySet= ThisDoc.Document.PropertySets.Item("Inventor User Defined Properties")

Dim dtDate As Date = Now

Dim iprop(2) As String
iprop(1) = "Released for Construction"
iprop(2) = "Released for Review"

Try
  prop = customPropertySet.Item(iprop(1))
Catch
  customPropertySet.Add(dtDate, iprop(1))   
End Try

Try
  prop = customPropertySet.Item(iprop(2))
Catch
  customPropertySet.Add(dtDate, iprop(2))   
End Try

Here is a simpler method when working on the active document using ilogic shortcuts

Dim iprop(2) As String
iprop(1) = "Released for Construction"
iprop(2) = "Released for Review"

iProperties.Value("Custom", iprop(1)) = Now
iProperties.Value("Custom", iprop(2)) = Now

Hope this helps with your problem. Cheers!

[WCrihfield · Accepted solution]

Here is a simple example of creating a Date type Custom iProperty.

Dim oDoc As Document = ThisApplication.ActiveDocument
Dim oPropName As String = "Date Sample"
Dim oPropValue As Date = FormatDateTime(Now,DateFormat.GeneralDate)
iProperties.Value("Custom",oPropName) = oPropValue

[maxim.teleguz]

I Found a better method, hint: pay attention to errors and use them. 

'can use in drawing or model or part, doesnt matter

Try
	If (ThisDrawing.ModelDocument Is Nothing) Then Return
		modelName = IO.Path.GetFileName(ThisDrawing.ModelDocument.FullFileName)
Catch
		modelName = IO.Path.GetFileName(modelName)
End Try

Try
	If iProperties.Value(modelName, "Custom", "Ref. Number") = Nothing Then
	'if not exist causes error
	End If
Catch
	'create it
	iProperties.Value(modelName, "Custom", "Ref. Number") = ""
End Try

[WCrihfield]

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:

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:

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.

[maxim.teleguz]

this is why my code is more efficient, look at your answer and then realize how long the code would be to check if the custom property exists or not and then create it if it doesnt. 

I dont even have to set any options in my code it is all native. 

[maxim.teleguz]

It just crossed my mind to show you this:

This is the smallest code in all of the internet for "checking" and creating custom properties if they are "missing"

Try
	If iProperties.Value("Custom", "Ref. Number") = Nothing Then
	'if not exist causes error
	End If
Catch
	'create it
	iProperties.Value("Custom", "Ref. Number") = ""
End Try

[WCrihfield]

Hi @maxim.teleguz.  Just as a test, and for the fun of it, I decided to test the performance of two iLogic rules within the same document that are both given the same exact task.  Both rules will first check to see if an iProperty exists, then create it if it did not exist yet.  Each time they are ran, I ensure that the iProperty does not already exist, before running it.

The one rule is using the 'shortest' or least amount of code possible, by using the iLogic only snippet 'iProperties.Value()', and uses a Try...Catch block to avoid the expected error.

Try
	i = iProperties.Value("Custom", "1")
Catch
	iProperties.Value("Custom", "1") = 1
End Try

The other rule is using only Inventor API code (no iLogic only snippets) and the traditional routine of using a 'For Each' loop and 'If...Then' statements to find the existing property, and then create the property if it is not found.

oCProps = ThisApplication.ActiveDocument.PropertySets.Item("Inventor User Defined Properties")
Dim oMyCProp As Inventor.Property = Nothing
If oCProps.Count > 0 Then
	For Each oCProp As Inventor.Property In oCProps
		If oCProp.Name = "1" Then
			oMyCProp = oCProp
			Exit For
		End If
	Next
End If
If IsNothing(oMyCProp) Then
	oMyCProp = oCProps.Add(1, "1")
End If

I used a code based stopwatch to monitor the time it took for each to perform its task, then ran each rule multiple times to compare performance.  Three typical finishing times for the first rule (the short one) were:  0.07 seconds, 0.091 seconds, and 0.065 seconds.  Three typical finishing times for the second rule (the longer one) were:  0.008 seconds, 0.015 seconds, and 0.013 seconds.  It was pretty clear that the longer, more proper API code rule won out over the coder's shortcut rule in performance, just as I attempted to explain before.  There may not be much difference when only working with a single property in a single, simple part document, but when your code is working through 10's of properties in each referenced document within all levels of a large complex assembly, this bit of code may be used many hundreds of times (if not thousands), and the difference in performance will definitely be appreciated, or even needed.

What some folks may knot realize is that there is a larger routine block of code that gets ran in the background to process the request every time you use the iProperties.Value() snippet.  And in more complex situations, it is not always very clear which document it will be acting upon, even when using the provided means to specify which one you want it to act upon.  The Try...Catch statement is definitely a great tool for handling expected errors, and has been a basic component of the vb.net system for a long time.  I use it quite often throughout my automation solutions, when there is no other way to avoid an expected error.  But in cases where there is another way to avoid that expected error, the other way is often going to perform better, even if it may take a bit more code.

[Curtis_Waguespack]

Just a quick point of clarification

This iLogic function checks for the iproperty and creates and sets it if does not exist. It does all of that in this one line.

iProperties.Value("Custom", "Foo") = "hello world"

If we are getting the iproperty value using the same iLogic function, then we will get an error if it does not exist, and so it's best to wrap this in a try/catch.

Try
oFoo = iProperties.Value("Custom", "Foo") 
Catch
End Try

This can be written as one line also:

Try : oFoo = iProperties.Value("Custom", "Foo") : Catch : End Try

or as such:

Try : oFoo = iProperties.Value("Custom", "Foo") : Catch : MsgBox("iprop not found") : End Try

I hope this helps.
Best of luck to you in all of your Inventor pursuits,
Curtis
http://inventortrenches.blogspot.com

[maxim.teleguz]

the issue is check to see if it exists, because we want to reuse the existing parameter if it exists. 

You are assuming we always want to re-write that parameter. 

....though you showed us some really cool tricks I haven't seen yet.

[Curtis_Waguespack]

---

@maxim.teleguz wrote:

the issue is check to see if it exists, because we want to reuse the existing parameter if it exists. 

You are assuming we always want to re-write that parameter. 

....though you showed us some really cool tricks I haven't seen yet.

---

Hi @maxim.teleguz ,

I wasn't speaking about parameters, but about iProperties, and my reply wasn't assuming anyone's intent, but just sharing some information and attempting to provide some clarification in case it helps someone.

But to your point, you are correct, the 1st example does both check and set the iproperty, as I stated previously. If the intent was not to set the value, then that would indeed not be the right choice to use.

The 2nd, 3rd, and 4th examples I shared, all check for the existence of the iproperty, but don't set it.

There are several combinations of using the iLogic iProperties function to get and set a custom iproperty that can be  used for different tasks. And understanding what the iLogic iProperties function is doing in each case is helpful in knowing what to include and exclude, and when to do so. 

 As an example, in post 4 and 7 of this thread, the "if iprop = nothing" statement you used in the Try statement is not necessary, because the ilogic iPropertiy function is doing the check already.

So you could eliminate that if you wanted to do so, and just use something like this, which is similar to Sergio's example in post 2

Try
	'if not exist causes error
	oTest = iProperties.Value("Custom", "Ref. Number")
Catch
	'create it
	iProperties.Value("Custom", "Ref. Number") = ""
End Try

Or maybe  even something like this:

p = "Ref. Number"
Try : x = iProperties.Value("Custom", p) : Catch : iProperties.Value("Custom", p) = "" : End Try

In any case, since the original question was about Date parameters, I have marked the posts that addressed the date type mismatch issue as solutions.

I hope this helps.
Best of luck to you in all of your Inventor pursuits,
Curtis
http://inventortrenches.blogspot.com

[maxim.teleguz]

i really do like this solution:

p = "Ref. Number"
Try : x = iProperties.Value("Custom", p) : Catch : iProperties.Value("Custom", p) = "" : End Try