how can this linie of code make a error?

[Darkforce_the_ilogic_guy]

how can this linie of code make a error?  we use this code for basicly 10 years now . I don´t understand how it can fail

[Michael.Navara]

The part can be un-modifiable for some reason. Check it before modify property

Logger.Debug(ThisDoc.Document.IsModifiable)

[WCrihfield]

In addition to what Michael mentioned...since that line of code "iProperties.Value()" does not specify which document it will be accessing the custom iProperty of, it may be trying to access that custom iProperty in the wrong document, and that other document may be treated as ReadOnly from Inventor's perspective, such as Content Center member, iPart/iAssembly member, ModelState member, or file located in a location defined as a library.  Unfortunately, there is not good official documentation about which document that code will try to access in all the various situations it is possible to use it in.

We can only assume that it will be trying to access the same document that we would get from the 'ThisDoc.Document' property in that situation, but there again, that property is not very well explained either.  If used within an 'internal' iLogic rule (one that is saved within an Inventor Document), then the 'ThisDoc.Document' property should be pointing to the Document that the rule is saved within.  But when that term is used in an external iLogic rule, it does not specify which Document it will be pointing to, but based on experience, by default it will usually be pointing to the Document that was 'active' when that external rule was first launched to run.  However, it can be pointing to different documents in different scenarios, such as when the rule was triggered to run by an event in the 'Event Triggers' dialog, it will be pointing to the Document where the event was triggered in.  And when using the 'iLogicVb.Automation.RunExternalRule() method', where you can specify a Document for the rule to focus on, it will be pointing to that specified document.  It's relatively dynamic and complicated.  However, if using the 'ThisApplication.ActiveDocument' phrase, that does not play by any of those rules, and will always simply point to whichever document was 'active' (visibly showing on your screen) at that point in the code where that line of code is encountered.

[Frederick_Law]

The iProperty does not exist.

The iProperty exist but with different data type.

[WCrihfield]

The behavior is different between 'Read' and 'Write' access, when using that iLogic API only tool.

• When trying to 'Read' (get the value only) of any iProperty, and either the PropertySet specified, or the Property specified does not exist, it will throw an error.
• When trying to 'Write' (set the value) of an iProperty using this tool:
  • If the "Custom" PropertySet is specified, and the Property name specified can not be found, it will automatically try to create that custom Property, using the name specified, and set its value to the value you specified.
  • If one of the first 3 PropertySets is specified, and it can not find the Property name specified, it will throw an error.
  • This is one of the advantages of using this iLogic API tool, versus the Inventor API route.

Whether using this iLogic API tool, or the Inventor API route to set the value of an iProperty, the value type seems to go by the following rules:

• If accessing a 'standard' property (from one of the first 3 PropertySets), and the data type you are trying to set as the new value does not match what is expected, it would throw an error, because most of those are properties are internally controlled (and several of them are ReadOnly anyways).
• If accessing a 'custom' property (in a custom PropertySet), we can change the property's value type by simply changing the value...as long as it is one of the acceptable types (String, Double, Date or Boolean).

[Darkforce_the_ilogic_guy]

just to give some Bonus info. This code is is used to add information about the material on sheet metal parts. and code are add in the begin to make sure this code only run on sheet metal part.

The templete for our sheet part does not have this properties , so  it use be create the first time it save the file.. and it seeem on other part create the same way to create this as a TEXT / string. I understand that if I was reading the properties and it wasn´t there the code will fail , but I am updating/Creating the properties. And as far as I how this error have only happen ones.  and we are likely maken 50-100 of them a day without no problem . I am only asking to improve my code and understand what is going wrong

[WCrihfield]

If you are using that code 50-100 times per day for quite a while and only had a problem once, that is pretty good performance.  Is it possible that one of the files being accessed by the code at that point in time was also being accessed by another person, or some other application on your computer when that error happened?  If so, that one file may have temporarily acted like ReadOnly, causing the error.  The initial check of the 'IsModifiable' property, suggested by Michael, would be the best option to avoid that potential issue.  However, checking the value of that property requires having a reference to the actual Document object that you will be accessing the iProperties of within that Sub routine.  So, maybe the next best suggestion may be to send the document object to that Sub routine.  But then, since you would already have a reference to the Document readily available, I would suggest switching from using that iLogic API line of code, to using the Inventor API way of accessing its properties, to avoid the potential issue of wrong document being accessed.

If you are looking for ways to improve your existing code, either to avoid all potential errors, or to improve efficiency, or both, then there are lots of ideas.  It all depends on what data is available at that point in your code, and your coding style.  Using the iLogic API tools usually requires less code overall, but I am not sure if they are the most efficient, or fastest, or the most clear about how they will function in some situations.  I like using iLogic API tools in small, internal rules, but usually prefer the certainty of the Inventor API tools in my larger &/or more complex &/or external rules.  You may, or may not be aware of this, but when you use a line of iLogic API code like that, it causes an alternate block of code defined within the Inventor add-in resources to get ran in the background, where it is most likely primarily utilizing the Inventor API code anyways.  One of the differences of using iLogic API tools is that those tools generally require us to specify the 'names' of objects, instead of references to the actual objects themselves, which usually requires less code.  This does not mean that less 'work' or processing is being done, but often actually more, because it must first get access to the actual objects it needs, using those supplied names to find them, before it can do its primary task using Inventor API code internally.

Another thing that may help with performance (if that is a goal) is avoiding the use of Try...Catch...End Try statements, in favor of one or more simple If...Then statements, when the If...Then statements are sufficient to avoid an expected/potential error.

Some possible alternatives utilizing Try...Catch...End Try statements:

(shortest / simplest, but least control, and no feedback)

Sub UpdateMatrProperty(value As String)
	Try : iProperties.Value("Custom", "Raw Material") = value : Catch : End Try
End Sub

or (using nested Try statements, but still no feedback)

Sub UpdateMatrProperty(oDoc As Document, sValue As String)
	Try
		oDoc.PropertySets.Item(4).Item("Raw Material").Value = sValue
	Catch
		Try : oDoc.PropertySets.Item(4).Add(sValue, "Raw Material") : Catch : End Try
	End Try
End Sub

or (more control, no nested Try statements, with minimal feedback)

Sub UpdateMatrProperty(oDoc As Document, sValue As String)
	If (Not oDoc.IsModifiable) Then
		Logger.Debug(oDoc.DisplayName & " is not modifiable!")
		Return
	End If
	Dim oProp As Inventor.Property = Nothing
	Try : oProp = oDoc.PropertySets.Item(4).Item("Raw Material") : Catch : End Try
	If oProp Is Nothing Then
		Try : oProp = oDoc.PropertySets.Item(4).Add(sValue, "Raw Material") : Catch : End Try
	Else
		Try : oProp.Value = sValue : Catch : End Try
	End If
End Sub

There are lots of possibilities for how this could be done differently, including actually iterating through the custom properties checking property names to find the existing one.  If found, set its value.  If not found during iteration, then create it after the iteration.  The initial 'IsModifiable' check should avoid any other errors from happening.