Get the child (dependent) features of a Part Feature using iLogic/API?

[DRoam]

In the Part environment, we can right-click on a Part feature and click "Relationships..." to see a dialog with a list of its Parent and Child features. The list of Child features is particularly useful for determining what depends on the feature.

Is there any way to get this same "Children" list via the API? I don't see anything like "Children" or "Dependents" under the PartFeature object.

Suggestions how how to determine the children programmatically are welcome, but I would prefer a built-in property if one exists, as that will always be faster and more stable.

[J-Camper]

Looks like you're not the first person to ask this.  I found this post from 2017, so I guess it still hasn't been implemented:   determine-feature-relationships-via-api 

I couldn't find an Idea post about it either, but if you make an idea post I'll up-vote it as I would like to see this available as well.

[WCrihfield]

Good question.

Here's a quickie iLogic code I threw together for you.

See if this does what you want.

I have a bunch of code commented out, because it references an external Excel file with the chart of all the ObjectTypeEnum names, values, and descriptions.  You probably already have your own system set up for this though.

Sub Main
Dim oPDoc As PartDocument = ThisApplication.ActiveDocument
Dim oPDef As PartComponentDefinition = oPDoc.ComponentDefinition
Dim oMPane As BrowserPane = oPDoc.BrowserPanes.Item("Model")
Dim oFeatNode As BrowserNode
Dim oNodes As BrowserNodesEnumerator
For Each oPFeat As PartFeature In oPDef.Features
	oFeatNode = oMPane.GetBrowserNodeFromObject(oPFeat)
	oNodes = oFeatNode.AllReferencedNodes(oFeatNode.BrowserNodeDefinition)
Next
Dim oCol As ObjectCollection = ThisApplication.TransientObjects.CreateObjectCollection
For Each oNode As BrowserNode In oNodes
	oCol.Add(oNode.NativeObject)
Next
'Dim oName As String
For Each oObj In oCol
	'Call a Sub that identifies ObjectTypeEnum by its readable name
'	oName = GetTypeName(oObj)
'	MsgBox(oName)
	MsgBox(oObj.Type.ToString)
Next
End Sub

'Function GetTypeName(ByVal oObect As Object) As String
'If IsNothing(oSelection) Then Exit Function
'Dim oTypeValue As String = oObect.Type
'Dim oTypeName As String
'Dim oFile As String = "S:\Engineering\ObjectTypeEnum List.xlsx"
'Dim oSheet As String = "ObjectTypeEnum List"
'GoExcel.Open(oFile, oSheet)
'GoExcel.DisplayAlerts = False
'GoExcel.TitleRow = 1
'GoExcel.FindRowStart = 2
'Dim oNameColumn As String = "A"
'Dim oValueColumn As String = "B"
'Dim oDescColumn As String = "C"
'Try
'	Dim oRow As Integer = GoExcel.FindRow(oFile, oSheet, "Value", "=", oTypeValue)
'	oTypeName = GoExcel.CellValue(oNameColumn & oRow)
''	MsgBox("ObjectTypeEnum Name = " & GoExcel.CellValue(oNameColumn & oRow) & vbCr &
''	"ObjectTypeEnum Value = " & GoExcel.CellValue(oValueColumn & oRow) & vbCr &
''	"ObjectTypeEnum Description = " & GoExcel.CellValue(oDescColumn & oRow))
'Catch ex As Exception
'	MsgBox("Selected object's Type can't be retrieved")
'End Try
'Return oTypeName
'GoExcel.Close
'End Function

[DRoam]

Hi @WCrihfield, using AllReferencedNodes only works if the feature you're checking is something like a sketch that gets its node reproduced below each feature that uses it. This isn't the case for most things, like Extrusions or Work Planes. Thanks for the suggestion, though.

After giving it more thought, I think it would be tough to determine relationships for most entities. For example, it would be tough to determine everywhere  a plane is used, including: sketches on it, extrusions from/to it, projections of it into sketches, and countless other ways planes can be used. Likewise, Extrusions can be used for: sketches on their faces, projected faces/edges, mirrored features, and countless other ways.

I think the best bet is a built-in property that returns the same list as the "Relationships..." dialog. I'm hoping there's an API for that somewhere that I'm not seeing, but I'm beginning to doubt it...

[WCrihfield]

I only did one test using this code before posting it, and it returned the ObjectTypeEnum value for a kThreadFeatureObject, as expected.  My part was a simple one with an extruded rod with a ThreadFeature applied to it, among a few others.

But, you're probably right.

You would likely have to have a separate Sub or Function for each type of feature you might encounter, and every type of object you might have to inspect within each type of feature.

For instance, most part features have a SurfaceBodies object that contains all the bodies that the feature either created or modified.  If you're looking for any thing that wouldn't exist without this feature, you would have to dig deeper into those bodies to inspect them all.  But if you're only looking for other feature objects that either depend on, or wouldn't exist without the searched feature, instead of all other types of objects, it might not be as bad.  Either way, a 'tall order'.