How to copy "item" column to another column "#item" column using Ilogic

[manu.marjanen]

This code renumber item column. Code below

How to modify this code to copy "item" column to another "#Item" column?

Dim app As Inventor.Application = ThisApplication
Dim doc As Document = app.ActiveDocument
Dim compDef As AssemblyComponentDefinition = doc.ComponentDefinition
Dim Occ As ComponentOccurrence
Dim Count As Integer = 1

For Each itm In compDef.BOM.BOMViews(2).BOMRows
	itm.ItemNumber = Count
	Count = Count + 1
Next

[manu.marjanen]

This code renumber item column. Code below

How to modify this code to copy "item" column to another "#Item" column?

Dim app As Inventor.Application = ThisApplication
Dim doc As Document = app.ActiveDocument
Dim compDef As AssemblyComponentDefinition = doc.ComponentDefinition
Dim Occ As ComponentOccurrence
Dim Count As Integer = 1

For Each itm In compDef.BOM.BOMViews(2).BOMRows
	itm.ItemNumber = Count
	Count = Count + 1
Next

[WCrihfield · Accepted solution]

Hi @manu.marjanen.  I assume you added that extra column as a 'Custom iProperty' column, and that you don't need the rule to actually create that column, just copy the value from the Item column in each row to the cell in this #Item column of the same row.  The assembly BOM isn't quite as simple or easy to work with as a spreadsheet or table, so to modify the value in the cell in the #Item column of each row, you must access the document being represented by that row, then access that specific custom iProperty within that document.

Here is an example iLogic rule that should do what you want, if everything is set-up as expected.

If ThisApplication.ActiveDocumentType <> DocumentTypeEnum.kAssemblyDocumentObject Then
	MsgBox("An Assembly Document must be active for this rule to work. Exiting.",vbCritical, "WRONG DOCUMENT TYPE")
	Exit Sub
End If
Dim oADoc As AssemblyDocument = ThisApplication.ActiveDocument
Dim oBOMView As BOMView = oADoc.ComponentDefinition.BOM.BOMViews(2)
For Each oRow As BOMRow In oBOMView.BOMRows
	Dim oItem As Integer = oRow.ItemNumber
	Dim oRowDoc As Document = oRow.ComponentDefinitions(1).Document
	For Each oCProp As Inventor.Property In oRowDoc.PropertySets(4)
		If oCProp.Name = "#Item" Then
			oCProp.Value = oItem
			Exit For
		End If
	Next
Next

If this solved your problem, or answered your question, please click ACCEPT SOLUTION.
Or, if this helped you, please click (LIKE or KUDOS) 👍.

If you want and have time, I would appreciate your Vote(s) for My IDEAS :light_bulb:or you can Explore My CONTRIBUTIONS

[WCrihfield · Accepted solution]

Hi @manu.marjanen.  I assume you added that extra column as a 'Custom iProperty' column, and that you don't need the rule to actually create that column, just copy the value from the Item column in each row to the cell in this #Item column of the same row.  The assembly BOM isn't quite as simple or easy to work with as a spreadsheet or table, so to modify the value in the cell in the #Item column of each row, you must access the document being represented by that row, then access that specific custom iProperty within that document.

Here is an example iLogic rule that should do what you want, if everything is set-up as expected.

If ThisApplication.ActiveDocumentType <> DocumentTypeEnum.kAssemblyDocumentObject Then
	MsgBox("An Assembly Document must be active for this rule to work. Exiting.",vbCritical, "WRONG DOCUMENT TYPE")
	Exit Sub
End If
Dim oADoc As AssemblyDocument = ThisApplication.ActiveDocument
Dim oBOMView As BOMView = oADoc.ComponentDefinition.BOM.BOMViews(2)
For Each oRow As BOMRow In oBOMView.BOMRows
	Dim oItem As Integer = oRow.ItemNumber
	Dim oRowDoc As Document = oRow.ComponentDefinitions(1).Document
	For Each oCProp As Inventor.Property In oRowDoc.PropertySets(4)
		If oCProp.Name = "#Item" Then
			oCProp.Value = oItem
			Exit For
		End If
	Next
Next

If this solved your problem, or answered your question, please click ACCEPT SOLUTION.
Or, if this helped you, please click (LIKE or KUDOS) 👍.

If you want and have time, I would appreciate your Vote(s) for My IDEAS :light_bulb:or you can Explore My CONTRIBUTIONS

[manu.marjanen]

Some situations "item" number not move "#Item" columns. 

Can this be done somehow differently?

[manu.marjanen]

Some situations "item" number not move "#Item" columns. 

Can this be done somehow differently?

[WCrihfield]

I'm not sure how that could happen, so I'm not sure what change may be needed.  The rule is fairly simple...in loop of each BOMRow, get that row's ItemNumber, then set that ItemNumber as the value of the custom iProperty named "#Item" within the document being represented by that row.  Did your other rule for renumbering row item numbers get ran after you ran this rule?

[WCrihfield]

I'm not sure how that could happen, so I'm not sure what change may be needed.  The rule is fairly simple...in loop of each BOMRow, get that row's ItemNumber, then set that ItemNumber as the value of the custom iProperty named "#Item" within the document being represented by that row.  Did your other rule for renumbering row item numbers get ran after you ran this rule?

[manu.marjanen]

Renumbering has been done before this code.

[manu.marjanen]

Renumbering has been done before this code.

[WCrihfield · Accepted solution]

I just thought of something we haven't tried yet.  If you just added the column for a custom iProperty to your BOM, but didn't follow through with the additional command (usually under the right-click menu when you right click on the header of that new column) called "Add Custom iProperty (all components)", then that custom iProperty may not yet exist in all the components.  If it wasn't present in all the components, then it wouldn't have copied the ItemNumber over, because there was nothing to copy it over into, because it doesn't have that custom iProperty yet.

So, I added a bit of code to the rule that will create the custom iProperty if it isn't found.

If ThisApplication.ActiveDocumentType <> DocumentTypeEnum.kAssemblyDocumentObject Then
	MsgBox("An Assembly Document must be active for this rule to work. Exiting.",vbCritical, "WRONG DOCUMENT TYPE")
	Exit Sub
End If
Dim oADoc As AssemblyDocument = ThisApplication.ActiveDocument
Dim oBOMView As BOMView = oADoc.ComponentDefinition.BOM.BOMViews(2)
For Each oRow As BOMRow In oBOMView.BOMRows
	Dim oItem As Integer = oRow.ItemNumber
	If oItem = 0 Then
		MsgBox("Found a row with no ItemNumber or zero value.", , "")
		'Continue For 'to skip to next row
	End If
	Dim oRowDoc As Document = oRow.ComponentDefinitions(1).Document
	Dim oCProps As PropertySet = oRowDoc.PropertySets.Item(4)
	Dim oCProp As Inventor.Property
	Dim oExists As Boolean = False
	For Each oCProp In oCProps
		If oCProp.Name = "#Item" Then
			oCProp.Value = oItem
			oExists = True
			Exit For
		End If
	Next
	If Not oExists Then
		'that custom iProperty wasn't found in this document,
		'so create it and set its value to the ItemNumber (oItem)
		oCProp = oCProps.Add(oItem, "#Item")
	End If
Next

Give that a try.

[WCrihfield · Accepted solution]

I just thought of something we haven't tried yet.  If you just added the column for a custom iProperty to your BOM, but didn't follow through with the additional command (usually under the right-click menu when you right click on the header of that new column) called "Add Custom iProperty (all components)", then that custom iProperty may not yet exist in all the components.  If it wasn't present in all the components, then it wouldn't have copied the ItemNumber over, because there was nothing to copy it over into, because it doesn't have that custom iProperty yet.

So, I added a bit of code to the rule that will create the custom iProperty if it isn't found.

If ThisApplication.ActiveDocumentType <> DocumentTypeEnum.kAssemblyDocumentObject Then
	MsgBox("An Assembly Document must be active for this rule to work. Exiting.",vbCritical, "WRONG DOCUMENT TYPE")
	Exit Sub
End If
Dim oADoc As AssemblyDocument = ThisApplication.ActiveDocument
Dim oBOMView As BOMView = oADoc.ComponentDefinition.BOM.BOMViews(2)
For Each oRow As BOMRow In oBOMView.BOMRows
	Dim oItem As Integer = oRow.ItemNumber
	If oItem = 0 Then
		MsgBox("Found a row with no ItemNumber or zero value.", , "")
		'Continue For 'to skip to next row
	End If
	Dim oRowDoc As Document = oRow.ComponentDefinitions(1).Document
	Dim oCProps As PropertySet = oRowDoc.PropertySets.Item(4)
	Dim oCProp As Inventor.Property
	Dim oExists As Boolean = False
	For Each oCProp In oCProps
		If oCProp.Name = "#Item" Then
			oCProp.Value = oItem
			oExists = True
			Exit For
		End If
	Next
	If Not oExists Then
		'that custom iProperty wasn't found in this document,
		'so create it and set its value to the ItemNumber (oItem)
		oCProp = oCProps.Add(oItem, "#Item")
	End If
Next

Give that a try.

[manu.marjanen]

My mistake, your code worked fine. Thanks for help.

[manu.marjanen]

My mistake, your code worked fine. Thanks for help.

[gdeber]

It is possible to copy the item number to a Instance Property? I would like to use this in assemblies with CC components so I need to use Instances. 

[gdeber]

It is possible to copy the item number to a Instance Property? I would like to use this in assemblies with CC components so I need to use Instances. 

[WCrihfield]

Hi @gdeber.  That does sound possible.  Do you only want to work with the top level components, or do you need this to effect all lower level components (within sub assemblies) also?  If it should effect lower levels, then I assume that we would be working with the Structured view of the BOM, and it will be set to all levels.  If not, I would still assume structured view, but top level only.  Also, what do you want to name the Instance Property (exact spelling and capitalization)?

[WCrihfield]

Hi @gdeber.  That does sound possible.  Do you only want to work with the top level components, or do you need this to effect all lower level components (within sub assemblies) also?  If it should effect lower levels, then I assume that we would be working with the Structured view of the BOM, and it will be set to all levels.  If not, I would still assume structured view, but top level only.  Also, what do you want to name the Instance Property (exact spelling and capitalization)?

[gdeber]

On top level assembly only, and to use on Parts Only BOM. We call that Custom Property "BRK_ID"

[gdeber]

On top level assembly only, and to use on Parts Only BOM. We call that Custom Property "BRK_ID"

[WCrihfield]

Hi @gdeber.  Give this one a try.

Sub Main
	Dim oADoc As AssemblyDocument = TryCast(ThisDoc.Document, Inventor.AssemblyDocument)
	If oADoc Is Nothing Then Logger.Debug(iLogicVb.RuleName & " exited (Wrong DocumentType)") : Return
	Dim oBOM As Inventor.BOM = oADoc.ComponentDefinition.BOM
	oBOM.PartsOnlyViewEnabled = True
	Dim oBOMViews As BOMViews = oBOM.BOMViews
	Dim oPartsOnlyBOMView As Inventor.BOMView
	For Each oBOMView As Inventor.BOMView In oBOMViews
		If oBOMView.ViewType = BOMViewTypeEnum.kPartsOnlyBOMViewType Then
			oPartsOnlyBOMView = oBOMView
			Exit For
		End If
	Next 'oBOMView
	If oPartsOnlyBOMView Is Nothing Then Return
	Dim oRows As BOMRowsEnumerator = oPartsOnlyBOMView.BOMRows
	For Each oRow As BOMRow In oRows
		Dim oItemNum As Integer = oRow.ItemNumber
		Dim oRowOccs As ComponentOccurrencesEnumerator = oRow.ComponentOccurrences
		If oRowOccs.Count = 0 Then Continue For
		For Each oRowOcc As ComponentOccurrence In oRowOccs
			oRowOcc.OccurrencePropertySetsEnabled = True
			Dim oSet As Inventor.PropertySet = oRowOcc.OccurrencePropertySets.Item(1)
			Dim oProp As Inventor.Property = Nothing
			Dim sPropName As String = "BRK_ID"
			Try
				oProp = oSet.Item(sPropName)
			Catch
				oProp = oSet.Add(oItemNum, sPropName)
			End Try
			If oProp IsNot Nothing AndAlso oProp.Value <> oItemNum Then
				Try : oProp.Value = oItemNum : Catch : End Try
			End If
		Next 'oRowOcc
	Next 'oRow
	If oADoc.RequiresUpdate Then oADoc.Update2(True)
	'If oADoc.Dirty Then oADoc.Save2(True)
End Sub

If this solved your problem, or answered your question, please click ACCEPT SOLUTION .
Or, if this helped you, please click (LIKE or KUDOS) 👍.

[WCrihfield]

Hi @gdeber.  Give this one a try.

Sub Main
	Dim oADoc As AssemblyDocument = TryCast(ThisDoc.Document, Inventor.AssemblyDocument)
	If oADoc Is Nothing Then Logger.Debug(iLogicVb.RuleName & " exited (Wrong DocumentType)") : Return
	Dim oBOM As Inventor.BOM = oADoc.ComponentDefinition.BOM
	oBOM.PartsOnlyViewEnabled = True
	Dim oBOMViews As BOMViews = oBOM.BOMViews
	Dim oPartsOnlyBOMView As Inventor.BOMView
	For Each oBOMView As Inventor.BOMView In oBOMViews
		If oBOMView.ViewType = BOMViewTypeEnum.kPartsOnlyBOMViewType Then
			oPartsOnlyBOMView = oBOMView
			Exit For
		End If
	Next 'oBOMView
	If oPartsOnlyBOMView Is Nothing Then Return
	Dim oRows As BOMRowsEnumerator = oPartsOnlyBOMView.BOMRows
	For Each oRow As BOMRow In oRows
		Dim oItemNum As Integer = oRow.ItemNumber
		Dim oRowOccs As ComponentOccurrencesEnumerator = oRow.ComponentOccurrences
		If oRowOccs.Count = 0 Then Continue For
		For Each oRowOcc As ComponentOccurrence In oRowOccs
			oRowOcc.OccurrencePropertySetsEnabled = True
			Dim oSet As Inventor.PropertySet = oRowOcc.OccurrencePropertySets.Item(1)
			Dim oProp As Inventor.Property = Nothing
			Dim sPropName As String = "BRK_ID"
			Try
				oProp = oSet.Item(sPropName)
			Catch
				oProp = oSet.Add(oItemNum, sPropName)
			End Try
			If oProp IsNot Nothing AndAlso oProp.Value <> oItemNum Then
				Try : oProp.Value = oItemNum : Catch : End Try
			End If
		Next 'oRowOcc
	Next 'oRow
	If oADoc.RequiresUpdate Then oADoc.Update2(True)
	'If oADoc.Dirty Then oADoc.Save2(True)
End Sub

If this solved your problem, or answered your question, please click ACCEPT SOLUTION .
Or, if this helped you, please click (LIKE or KUDOS) 👍.

[gdeber]

It gives me an error en line 56...

"chain conversion "" on type "Double" not valid."

[gdeber]

It gives me an error en line 56...

"chain conversion "" on type "Double" not valid."

[WCrihfield]

Hi @gdeber.  The code I just posted only had 37 lines, so how could an error be happening on Line 56?  I think I do see something in the code I just posted that might cause a problem though.  On Line 17, it is declaring the 'oItemNum' variable as an Integer, then setting its value with the BOMRow.ItemNumber property, which I thought returned an Integer, but the online documentation says it returns a String.  So, that might cause an error attempting to convert a String into an Integer.  That could likely be fixed by replacing that line with the following line.

Dim oItemNum As String = oRow.ItemNumber

There should not be any conversion involving a Double data type in that code though.

[WCrihfield]

Hi @gdeber.  The code I just posted only had 37 lines, so how could an error be happening on Line 56?  I think I do see something in the code I just posted that might cause a problem though.  On Line 17, it is declaring the 'oItemNum' variable as an Integer, then setting its value with the BOMRow.ItemNumber property, which I thought returned an Integer, but the online documentation says it returns a String.  So, that might cause an error attempting to convert a String into an Integer.  That could likely be fixed by replacing that line with the following line.

Dim oItemNum As String = oRow.ItemNumber

There should not be any conversion involving a Double data type in that code though.

[gdeber]

Sorry, on line 30

If oProp IsNot Nothing AndAlso oProp.Value <> oItemNum Then

 This is the extended info on the error message:

"System.InvalidCastException: La conversión de la cadena "" en el tipo 'Double' no es válida. ---> System.FormatException: Input string was not in a correct format.
at Microsoft.VisualBasic.CompilerServices.Conversions.ParseDouble(String Value, NumberFormatInfo NumberFormat)
at Microsoft.VisualBasic.CompilerServices.Conversions.ToDouble(String Value, NumberFormatInfo NumberFormat)
--- End of inner exception stack trace ---
at Microsoft.VisualBasic.CompilerServices.Conversions.ToDouble(String Value, NumberFormatInfo NumberFormat)
at Microsoft.VisualBasic.CompilerServices.Operators.CompareObject2(Object Left, Object Right, Boolean TextCompare)
at Microsoft.VisualBasic.CompilerServices.Operators.ConditionalCompareObjectNotEqual(Object Left, Object Right, Boolean TextCompare)
at ThisRule.Main() in rule: Rule5, in document assembly for BOM.iam:line 30
at Autodesk.iLogic.Exec.AppDomExec.ExecRuleInAssembly(Assembly assem)
at iLogic.RuleEvalContainer.ExecRuleEval(String execRule)"

[gdeber]

Sorry, on line 30

If oProp IsNot Nothing AndAlso oProp.Value <> oItemNum Then

 This is the extended info on the error message:

"System.InvalidCastException: La conversión de la cadena "" en el tipo 'Double' no es válida. ---> System.FormatException: Input string was not in a correct format.
at Microsoft.VisualBasic.CompilerServices.Conversions.ParseDouble(String Value, NumberFormatInfo NumberFormat)
at Microsoft.VisualBasic.CompilerServices.Conversions.ToDouble(String Value, NumberFormatInfo NumberFormat)
--- End of inner exception stack trace ---
at Microsoft.VisualBasic.CompilerServices.Conversions.ToDouble(String Value, NumberFormatInfo NumberFormat)
at Microsoft.VisualBasic.CompilerServices.Operators.CompareObject2(Object Left, Object Right, Boolean TextCompare)
at Microsoft.VisualBasic.CompilerServices.Operators.ConditionalCompareObjectNotEqual(Object Left, Object Right, Boolean TextCompare)
at ThisRule.Main() in rule: Rule5, in document assembly for BOM.iam:line 30
at Autodesk.iLogic.Exec.AppDomExec.ExecRuleInAssembly(Assembly assem)
at iLogic.RuleEvalContainer.ExecRuleEval(String execRule)"

[WCrihfield]

Hi @gdeber.  Even after seeing the error message, I still do not understand why it is having any problems at that line of code.  The error message seems to indicate that it is encountering an error while trying to convert a String data type value into a Double data type value.  But I do not see anything in that code that would indicate a Double data type value.  And even if there were, I am not sure why it would be attempting to convert the Double data type value into a String data type value.

Below is the link to the online help documentation for the BOMRow.ItemNumber property.

https://help.autodesk.com/view/INVNTOR/2024/ENU/?guid=BOMRow_ItemNumber 

That documentation directly says that this property's value should be returned as a String, not a Double, and not an Integer.

Also, below the link to the online help documentation for the Property.Value (AKA: iProperty.Value) property, which says that its value is (a Variant in VBA, but an Object in VB.NET), not a String, Double, Integer, or any other specific type.

https://help.autodesk.com/view/INVNTOR/2024/ENU/?guid=Property_Value 

When we review these two documentations, then it should not matter what data type we get from the BOMRow.ItemNumber, because the Property.Value property can accept any of them.  So, there should not be a problem with trying to convert a String into a Double.

What version of Inventor are you using?

Is there more code in your rule than what I posted above?

What does your Item Number values look like?

[WCrihfield]

Hi @gdeber.  Even after seeing the error message, I still do not understand why it is having any problems at that line of code.  The error message seems to indicate that it is encountering an error while trying to convert a String data type value into a Double data type value.  But I do not see anything in that code that would indicate a Double data type value.  And even if there were, I am not sure why it would be attempting to convert the Double data type value into a String data type value.

Below is the link to the online help documentation for the BOMRow.ItemNumber property.

https://help.autodesk.com/view/INVNTOR/2024/ENU/?guid=BOMRow_ItemNumber 

That documentation directly says that this property's value should be returned as a String, not a Double, and not an Integer.

Also, below the link to the online help documentation for the Property.Value (AKA: iProperty.Value) property, which says that its value is (a Variant in VBA, but an Object in VB.NET), not a String, Double, Integer, or any other specific type.

https://help.autodesk.com/view/INVNTOR/2024/ENU/?guid=Property_Value 

When we review these two documentations, then it should not matter what data type we get from the BOMRow.ItemNumber, because the Property.Value property can accept any of them.  So, there should not be a problem with trying to convert a String into a Double.

What version of Inventor are you using?

Is there more code in your rule than what I posted above?

What does your Item Number values look like?

[gdeber]

Wesley, Im very sorry. I tried again the code in a new file and worked greate!

Thank you very much for your help.

Let me know if I can help you with something 😄

[gdeber]

Wesley, Im very sorry. I tried again the code in a new file and worked greate!

Thank you very much for your help.

Let me know if I can help you with something 😄

[gdeber]

OK. The code worked grate with asseblies with only components in it. But it isn't working with sub-assemblies.

If I do it manually, there's no problem.

Anybody can help me?

Thank's in advance.

[gdeber]

OK. The code worked grate with asseblies with only components in it. But it isn't working with sub-assemblies.

If I do it manually, there's no problem.

Anybody can help me?

Thank's in advance.

[WCrihfield]

Hi @gdeber.  Maybe.  We were working with the 'parts only' view of the BOM in that code example above.  That is a flat list of all parts, from all levels, which can also include weldment type assemblies since their BOMStructure is set to 'inseparable' by default, but will not include regular sub assemblies themselves.  This is different from the 'structured view', where it is set to include all levels.  In the structured all levels view, the same part file could possibly be referenced by multiple different assemblies at the same time...and if so, it could have a different Item Number value within each of the different assemblies' BOMs.  However, there would only actually be the one part file on disk, so, it would write one value to that file representing its Item Number within one assembly, but then overwrite that value with its Item Number from within some other assembly, and so on.  In the parts only view, there should not be any child rows, so no recursive processing should be needed, but if we switched to the structured view, set to all levels, then there could be child rows, and recursive processing would most likely be needed, which gets more complicated.

It is difficult to explain here, but the BOM of the main assembly looks at all its components from its own perspective, and there are several aspects of those components that can be customized in ways that are only custom from the perspective of that main assembly, without them being different from the perspective of any other sub assembly.  One of those things is the Item Number value within the BOM.  The Item Number value can even be (and often is) different between the Parts Only view and the Structured view of the same assembly, which is another concern to keep in mind.  Just another reason why writing assembly level data back down to part level is often not a good idea (but not always).  So, I am not sure what your expectation may be in those awkward types of situations.

Edit:  I may have mixed my words there...I know we are not actually planning on writing data to the actual part files, just to instance properties, which should all be recorded by the main assembly, I believe.  But this is not something that I do where I work, so maybe I'm wrong.  If the components are being edited in the context of the sub assemblies, then ModelStates may come into play here, which may potentially prevent some modifications at those levels, not sure.

[WCrihfield]

Hi @gdeber.  Maybe.  We were working with the 'parts only' view of the BOM in that code example above.  That is a flat list of all parts, from all levels, which can also include weldment type assemblies since their BOMStructure is set to 'inseparable' by default, but will not include regular sub assemblies themselves.  This is different from the 'structured view', where it is set to include all levels.  In the structured all levels view, the same part file could possibly be referenced by multiple different assemblies at the same time...and if so, it could have a different Item Number value within each of the different assemblies' BOMs.  However, there would only actually be the one part file on disk, so, it would write one value to that file representing its Item Number within one assembly, but then overwrite that value with its Item Number from within some other assembly, and so on.  In the parts only view, there should not be any child rows, so no recursive processing should be needed, but if we switched to the structured view, set to all levels, then there could be child rows, and recursive processing would most likely be needed, which gets more complicated.

It is difficult to explain here, but the BOM of the main assembly looks at all its components from its own perspective, and there are several aspects of those components that can be customized in ways that are only custom from the perspective of that main assembly, without them being different from the perspective of any other sub assembly.  One of those things is the Item Number value within the BOM.  The Item Number value can even be (and often is) different between the Parts Only view and the Structured view of the same assembly, which is another concern to keep in mind.  Just another reason why writing assembly level data back down to part level is often not a good idea (but not always).  So, I am not sure what your expectation may be in those awkward types of situations.

Edit:  I may have mixed my words there...I know we are not actually planning on writing data to the actual part files, just to instance properties, which should all be recorded by the main assembly, I believe.  But this is not something that I do where I work, so maybe I'm wrong.  If the components are being edited in the context of the sub assemblies, then ModelStates may come into play here, which may potentially prevent some modifications at those levels, not sure.

[gdeber]

Yes, I understand the complexity between the diferente BOM representation. That's why we work on a instance value and not in the actual part parameter. When I copy the value manually there is no conflict at all. Honestly I don't know what the problem is. The error message is: "Error catastrófico (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))" on line 21 ("oRowOcc.OccurrencePropertySetsEnabled = True").

I am thankful for any kind of help.

[gdeber]

Yes, I understand the complexity between the diferente BOM representation. That's why we work on a instance value and not in the actual part parameter. When I copy the value manually there is no conflict at all. Honestly I don't know what the problem is. The error message is: "Error catastrófico (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))" on line 21 ("oRowOcc.OccurrencePropertySetsEnabled = True").

I am thankful for any kind of help.