Is kWeldsComponentDefinition incorrectly derived?

Is kWeldsComponentDefinition incorrectly derived?

skotzur
Contributor Contributor
421 Views
3 Replies
Message 1 of 4

Is kWeldsComponentDefinition incorrectly derived?

skotzur
Contributor
Contributor

The API notes that kWeldsComponentDefinitionObject is derived from kPartComponentDefinitionObject. This doesn't make perfect sense since (I think) this is the "Welds" node that shows the beads in the browser for a Weldment Assembly, but the data lives in the assembly document; it is not a unique file. It does seem to count as a "LeafNode" though when traversing the assembly using something like the code found in this post.

 

Anyway, assuming that it is derived from the kPartComponentDefinition, and that's correct...

 

When a conditional statement is used to look for only assembly occurrences, these welds make it through.

 

This came up because I was trying to iterate through an assembly and apply a ModelState to any assembly document, and ModelState cannot be applied to weld components, so it was throwing an error.

 

I know just enough of OOP to dig myself a nice hole, but not enough to get out sometimes. Is this a bug, or am I thinking of this wrong?

 

I made the code below to demonstrate what's confusing me. Please note that this routine isn't iterative, so it needs to be run directly on an assembly that has been converted to a weldment

 

 

Sub main()
	
	Dim oDoc As AssemblyDocument
	oDoc = ThisApplication.ActiveDocument
	
	'Get Active Document Component Definition
	Dim oAsmCompDef As AssemblyComponentDefinition
	oAsmCompDef = oDoc.ComponentDefinition
	If oAsmCompDef.Type <> kWeldmentComponentDefinitionObject Then
		MessageBox.Show("This can only be demonstated on a Weldment document. Please run this program in a Weldment Assembly with the ""Welds"" shown in the Browser  " & oAsmCompDef.Type)
	
	Else
		For Each oOcc In oAsmCompDef.Occurrences
			Dim docFNmae As String		
			Dim oOccDef As ComponentDefinition
			oOccDef = oOcc.Definition
			oOccName = oOcc.Name
			oOccType = oOccDef.Type
			
			If oOcc.DefinitionDocumentType = DocumentTypeEnum.kAssemblyDocumentObject Then 
				If oOcc.Definition.Type = ObjectTypeEnum.kWeldsComponentDefinitionObject
					MessageBox.Show("This occurence, I think, is the ""Welds"" shown in the browser & ComponentDefinition = kWeldsComponenetDefinitionObject. According to the API it is supposed to be derived from the kPartComponentDefinitionObject but is making it through a ComponenetDefinition = kAssemblyComponentDefinition conditional statement." & vbCr & vbCr &" ComponentDefinition.Type: " & oOccType)
				End If
			End If 

		Next
	End If
End Sub

 

 

 

 

0 Likes
Accepted solutions (2)
422 Views
3 Replies
Replies (3)
Message 2 of 4

WCrihfield
Mentor
Mentor

I've seen this before too a while back, and I think I may have used the "Was this helpful?" tool at the bottom of that page to let them know about it.  I believe the WeldsComponentDefinition is only found within a WeldmentComponentDefinition, which is obviously the sub type of an AssemblyComponentDefinition that has been converted to a weldment type assembly.  It might possibly be loosely derived from a PartComponentDefinition Class block of code, due to what it provides access to, but doesn't really have anything to do with a PartDocument, specifically.  At least that's my understanding, but I'm not an Autodesk software development employee, so...

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

Message 3 of 4

skotzur
Contributor
Contributor
Accepted solution

I think the nuance that I was missing is the difference between the "Definition" and the "definitionDocumentType". Welds are not their own Document, but they are their own Object.

 

So oOcc.Definition.Type is kWeldsComponentDefinitionObject

 

but the DOCUMENT for the Welds Object is whatever assembly they reside in...

image.png

 

For example, in the above Screenshot, the "Welds" is it's own object and is of the type kWeldsComponentDefinitionObject. The DOCUMENT that the Welds object exists in is the assembly doc ETM-TEST4.iam, so the oOcc.DefinitionDocumentType is kAssemblyDocumentObject.

 

I would imagine that there may exist some sort of feature which is an object that you would add to a part file that is derived from a  PartFeatureObject. In that case:

  • oOcc.definition.Type = kSomeSortOfFeatureComponentDefinitionObject because that's the Type of the actual object
  • oOcc.DefinitionDocumentType = kPartDocumentObject because that's the Document that oOcc resides in is a part

 

Message 4 of 4

WCrihfield
Mentor
Mentor
Accepted solution

Yes.  I did find it to be interesting that it counts the 'Welds' node in the model browser of a weldment type assembly as a ComponentOccurrence.  And because it has a 'Definition' as a WeldsComponentDefinition, it then gives us similar access to the objects below it as other ComponentDefinition types do (Occurrences, SurfaceBodies, BOMQuantity, BOMStructure, etc.).  I also thought it was interesting that even though the weldment assembly I was testing code on included 3 individual welds in the model browser, and the WeldsComponentDefinition.Welds.Count reflected that correctly, but then there were zero occurrences, and only one SurfaceBody within the WeldsComponentDefinition.  I'm guessing this is just like in a PartComponentDefinition, because it also contains an Occurrences property that is rarely used, and normally all new geometry is added to the main SurfaceBody, unless you specify that you want it to be a new SurfaceBody.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)