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
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 💡or you can Explore My CONTRIBUTIONS
Wesley Crihfield
(Not an Autodesk Employee)
Some situations "item" number not move "#Item" columns.
Can this be done somehow differently?
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?
Wesley Crihfield
(Not an Autodesk Employee)
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
NextGive that a try.
Wesley Crihfield
(Not an Autodesk Employee)
Hi @gabriel_deber. 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)?
Wesley Crihfield
(Not an Autodesk Employee)
Hi @gabriel_deber. 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 SubIf this solved your problem, or answered your question, please click ACCEPT SOLUTION .
Or, if this helped you, please click (LIKE or KUDOS) 👍.
Wesley Crihfield
(Not an Autodesk Employee)
Hi @gabriel_deber. 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.ItemNumberThere should not be any conversion involving a Double data type in that code though.
Wesley Crihfield
(Not an Autodesk Employee)
Hi @gabriel_deber. 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?
Wesley Crihfield
(Not an Autodesk Employee)
Hi @gabriel_deber. 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.
Wesley Crihfield
(Not an Autodesk Employee)
