collapse all children

collapse all children

nbonnett-murphy
Advocate Advocate
867 Views
5 Replies
Message 1 of 6

collapse all children

nbonnett-murphy
Advocate
Advocate

Hello, I'm trying to make an iLogic script to collapse all nodes in the browser. I know there's a right click menu option for that, but I'd like to have a keyboard shortcut for it.

 

This is what I have so far. It's working correctly, but for obvious reasons, it takes forever to run in large assemblies.

Sub main
	Dim oDoc As Document = ThisApplication.ActiveDocument
	Dim oTopNode As BrowserNode
	oTopNode = oDoc.BrowserPanes.ActivePane.TopNode

	recurse(oTopNode)

End Sub

Sub recurse(oTopNodefx)
	Dim oNode As BrowserNode

	For Each oNode In oTopNodefx.BrowserNodes
		'check if there are any children under the ref'd node
		If oNode.BrowserNodes.Count <> 0
			'logger.info(oNode.BrowserNodeDefinition.Label)
			'logger.info(oNode.BrowserNodes.Count)
			'Exit Sub
			recurse(oNode)  
		End If
		If oNode.Visible = True And oNode.Expanded = True Then
			oNode.Expanded = False
		End If
	Next
End Sub

Does anyone have a faster way than recursively drilling down to every single node? Is the "collapse all children" function accessible via the command manager?

0 Likes
Accepted solutions (1)
868 Views
5 Replies
Replies (5)
Message 2 of 6

nbonnett-murphy
Advocate
Advocate

Disregard...

You can get "collapse all children" from the command manager. All it takes is:

ThisApplication.CommandManager.ControlDefinitions.Item("AppBrowserCollapseAllCmd").Execute

 

I am still curious if there's a faster way to dig through browser nodes though. It might come up later, and the recursive function is super slow.

Message 3 of 6

WCrihfield
Mentor
Mentor
Accepted solution

Hi @nbonnett-murphy.  If you truly need to collapse every single sub node at every level, before collapsing the top/main node, then there are no super fast shortcuts, because a lot of objects and properties need to be checked along the way.  However, it looks to me like your code may be iterating down into every single node branch, whether it needs to be iterated or not.  Before iterating deeper down into a browser node branch, maybe check if it is visible & expanded.  If it is not, then none of its sub nodes should be both visible and expanded.  But then again, I guess it all comes down to how thorough you need/want to be.  If a sub, sub node was expanded, but then its parent, parent note was collapsed, you may still want to dig down to that one that was left expanded before its parent, parent node was collapsed, because if you expand that parent, parent node again, the sub, sub node will automatically be expanded, based on its previous status.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

0 Likes
Message 4 of 6

nbonnett-murphy
Advocate
Advocate

Thanks for the info Wesley. I was trying to collapse all nodes in this case, and I see what you mean about expanded nodes underneath collapsed parents. I could probably pare it down by only checking assembly objects, and skipping standard folders like "representations" and "origin".

 

In any case, command manager to the rescue on this one 🙂

Message 5 of 6

WCrihfield
Mentor
Mentor

Yep, usually the folks who designed all that stuff know how to control it better (and more efficiently) than we do.  However, even though your code is already pretty basic and simple already, there may be a couple tiny changes that could be made that may very slightly improve performance.  When using a For Each...Next type iteration, if the 'Count' of the collection it is supposed to iterate over is zero, it will not throw an error, but will simply not have anything to do, so it will go to the next task in the code, so you can eliminate a couple lines of code by eliminating that If...Then statement, but leaving the call to recurse the current node.  If it does not have any sub nodes, then nothing will happen.  Next, we'll take a look at your second If...Then statement.  There is actually a 'shortcut' we can use there, so that if the first thing is not True, it will not even check the second thing, which could possibly reduce processing.  Instead of using 'And', try using 'AndAlso'.  If using 'And', both arguments will always be evaluated, but if using 'AndAlso' the second argument will only be evaluated if the first argument passed the test.

 

Sub Main
	Dim oDoc As Inventor.Document = ThisApplication.ActiveDocument
	RecurseBrowserNodes(oDoc.BrowserPanes.ActivePane.TopNode)
End Sub

Sub RecurseBrowserNodes(ThisNode As Inventor.BrowserNode)
	Dim oChildNode As Inventor.BrowserNode
	For Each oChildNode In ThisNode.BrowserNodes
		RecurseBrowserNodes(oChildNode)
		If oChildNode.Visible AndAlso oChildNode.Expanded Then
			oChildNode.Expanded = False
		End If
	Next oChildNode
End Sub

Another way this could be set-up, is to modify the recursive Sub routine to accept the BrowserNodesEnumerator object, instead of the BrowserNode object, but I am not sure if that would make any efficiency/performance difference without further testing.  The BrowserNodesEnumerator object is the Type you get as the value of BrowserNode.BrowserNodes property.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

Message 6 of 6

nbonnett-murphy
Advocate
Advocate

Thanks for the help, this is very informative. I wasn't aware of "AndAlso" at all. Optimization is something I haven't had to deal with in the past, and I'm sure I'll be looking back at this post next time it comes up.

0 Likes