Announcements
Attention for Customers without Multi-Factor Authentication or Single Sign-On - OTP Verification rolls out April 2025. Read all about it here.

Hi @checkcheck_master.  Document parent is sort of the wrong terminology for what we are looking for, but even what we are looking for here is like smoke and mirrors.  Sometimes it does not exist...sometimes if there should be one, it will not be found...sometimes there will be multiple and will return the wrong one.  Even though the Document object has a Parent property, its value is a generic Object, and will usually just return the Application object, instead of whatever assembly document or component definition this document may be directly referenced within as a component.  Using the Document.ReferencingDocuments route, depends on the higher level documents being currently either initialized or open (in-memory) to find them, then if the document is more than one level deep in an assembly, it may return the top level assembly along with every other sub assembly it is in above that point, and it may not be obvious which one of the multiple to choose without seeing the list and choosing the right one.

 

In my test using the iLogic code below and a testing assembly document, I chose a part that was within a weldment sub assembly, and that weldment was a top level component.  In this situation, the top level assembly, and the weldment sub assembly were both in the list of documents referencing the part, but the weldment sub assembly was the second one in the list, not the first.  (Components representing that part were also within the top level of the assembly.)  Here is the code I used for that test.

Dim oADoc As AssemblyDocument = ThisDoc.Document
oADef = oADoc.ComponentDefinition
oOccs = oADef.Occurrences
'top level sub assembly weldment
oTopOcc = oOccs.ItemByName("Weldment BOM sample:1")
'part within that sub assembly
oSubOcc = oTopOcc.Definition.Occurrences.ItemByName("Part1:1")
Dim oSubOccDoc As Document = oSubOcc.ReferencedDocumentDescriptor.ReferencedDocument
Dim oParentDoc As Document = Nothing
'this won't work...returns Application
'oParentDoc = oSubOccDoc.Parent
oUpRefDocs = oSubOccDoc.ReferencingDocuments
If oUpRefDocs.Count = 0 Then
	MsgBox("No In-Memory Documents found referencing this doc.", , "")
ElseIf oUpRefDocs.Count = 1 Then
	oParentDoc = oUpRefDocs.Item(1)
ElseIf oUpRefDocs.Count > 1 Then
	'oParentDoc = oUpRefDocs.Item(1)
	'or
	Dim oUpRefDocNames As New List(Of String)
	For Each oUpRefDoc As Document In oUpRefDocs
		oUpRefDocNames.Add(oUpRefDoc.FullDocumentName)
	Next
	oUpRefDocName = InputListBox("", oUpRefDocNames, "", "Referencing Documents", "List Of Referencing Documents")
	For Each oUpRefDoc As Document In oUpRefDocs
		If oUpRefDoc.FullDocumentName = oUpRefDocName Then
			oParentDoc = oUpRefDoc
		End If
	Next
End If
If oParentDoc Is Nothing Then
	MsgBox("No 'Parent' doc found.", , "")
Else
	Dim oBOMStr As BOMStructureEnum = oParentDoc.ComponentDefinition.BOMStructure
	MsgBox("'Parent' doc name = " & oParentDoc.FullDocumentName & vbCrLf & _
	"and its BOMStructure is set to " & oBOMStr.ToString, , "")
End If

Pertaining to checking iProperties:

As far as retrieving several iPropeties from multiple documents and the right process for it to avoid errors...I would have to say that if it can be done without using a Try...Catch block and still avoid errors, then that is likely the best route, but if you don't know of any other way to avoid expected potential errors, then use the Try...Catch block.  In cases concerning things like Parameters & iProperties, you can usually just loop through them to find whether or not the parameter or property exists, either using something like a Boolean variable, or a pre-defined variable to hold the found object.  Then after the loop, check your Boolean or your variable to see if it is False or Nothing.  That is often the better alternative, when possible, instead of a Try...Catch block.  However, I generally advise folks to keep the contents within the Try...Catch block as brief, simple, and to the point as possible.  Just the one problem line, or just the few lines that are testing an error prone object/method.  And I also generally advise folks to make use of the Catch side, instead of just leaving it empty.  Even if it's just to write something about the error to the logger in the background.  It can be a huge help if/when you need to debut problems later.

 

Pertaining to putting an assembly and its children into a folder, and possible iteration techniques:

I assume you are talking about a BrowserFolder in the model BrowserPane?  I would assume that when you move the assembly into a folder that all its children would also automatically stay with the assembly, into the folder, unless I'm missing some sort of special detail.  As far as which iteration process is best...it is probably just a personal preference, rather than necessity or advantage in many situations, but I suppose if you are looking for quantities, then that's part of what the BOM is for, so that might be a more logical choice.  For most other tasks I personally usually prefer iterating the assembly by either its ReferencedDocuments or its Occurrences, depending on what I'm trying to accomplish.  But I generally just don't need to work with the BOM by code as heavily or with as much customization as a lot of others, so I may be leaning that way due to being far more familiar with it.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)