Utilizing MakePath in SelectSet.Select
Hi @Anders_Olsen. I could be wrong, because I rarely use that specific uniquely iLogic snippet, but I think you may need to enclose the two quoted component names within the { & } characters, to simulate them being two elements of an 'Array' ({"75430:2", "75424:1"}). Of course, there are also alternative ways to get the lower level component occurrence, such as the example below which starts from a uniquely iLogic object, then transitions to Inventor API code for the rest.
ThisAssembly.Document.ComponentDefinition.Occurrences("75430:2").Definition.Occurrences("75424:1")ICadComponent.InventorComponent Property
Wesley Crihfield
(Not an Autodesk Employee)
Ah, I see. I see that sort of thing a lot. Sometimes we just need to separate complex lines of code out a bit, and do a better job of defining their Types to get things to work. And yes, I forgot that the 'ItemByName' property is not he 'default' one when trying to shorten the line of code to eliminate a couple steps. I tend to do most things through Inventor API code, even though it usually requires more code, because it usually makes more logical sense to me or provides better/clearer control. I too went through a long phase where I was attempting to make everything as condensed as possible, but I got over it, and opted for code that had better performance and was easier to read through and understand again at a later date. My 'production' related codes and the stuff I post online are usually pretty different. My production related codes usually contain lots of comments, error avoidance checks with some form(s) of feedback, are designed for best performance...and usually get tweaked lots of times as my knowledge and coding style changes.
Wesley Crihfield
(Not an Autodesk Employee)
If you are iterating through a list (or dictionary, or similar) of String type values, and will be getting several different component occurrences during that process, I would suggest getting the ComponentOccurrences collection to a variable first (before the iteration starts), from the AssemblyComponentDefinition.Occurrences property. Also get the SelectSet object to a variable before the iteration starts. Those steps will eliminate a lot of little API calls later, making it more efficient. Then I would suggest declaring a ComponentOccurrence Type variable that you will later be setting the value of, so that it has a predefined Type, no matter how you set its value. Then, after you have set the value of that variable in a later line of code, put the code for selecting it on the next line, where the input into that select method is that component variable. Then whatever you are planning on doing with it in other lines of code after that point.
But I simply do not know enough yet about the details of your overall design intent or plans to suggest much else yet, or provide a working code example. If your list only contains the part number (or file name) of the lower level component, but not the name of its parent sub assembly, then a different strategy may be necessary. Maybe get the referenced document with that part number (or file name) first, then use the ComponentOccurrences.AllReferencedOccurrences method to get all of the occurrences throughout the entire assembly structure that reference it, then iterate through them, selecting each one and doing your thing with them. That way you are not iterating through all occurrences in every level recursively looking for them, but just going directly to the ones you want to do something with. Each occurrence object has the OccurrencePath property also, which returns an ComponentOccurrencesEnumerator that we can convert to an array of Strings or ArrayList, if necessary, but that may be regressing.
Edit: Here is a 'shot in the dark' example code, without knowing what your full plans are yet.
Sub Main Dim oADoc As AssemblyDocument = TryCast(ThisApplication.ActiveDocument, Inventor.AssemblyDocument) If oADoc Is Nothing Then Logger.Debug("Rule named '" & iLogicVb.RuleName & "' did not run because no assembly obtained!") Return End If Dim oSS As Inventor.SelectSet = oADoc.SelectSet Dim oOccs As ComponentOccurrences = oADoc.ComponentDefinition.Occurrences Dim oAllRefDocs As DocumentsEnumerator = oADoc.AllReferencedDocuments Dim oListOfPNs As List(Of String) oListOfPNs.Add("75430") oListOfPNs.Add("75424") For Each sPN As String In oListOfPNs 'get the referenced Document with this Part Number (or FileName) For Each oRefDoc As Inventor.Document In oAllRefDocs Dim sPartNumber As String = oRefDoc.PropertySets.Item(3).Item(2).Value If sPartNumber = sPN Then Dim oRefOccs As ComponentOccurrencesEnumerator = oOccs.AllReferencedOccurrences(oRefDoc) If (oRefOccs Is Nothing) OrElse (oRefOccs.Count = 0) Then Continue For For Each oRefOcc As Inventor.ComponentOccurrence In oOccs 'If oRefOcc.Name.StartsWith(sPN) Then oSS.Select(oRefOcc) '<<< DO SOMETHING WITH IT >>> Next 'oRefOcc End If Next 'oRefDoc Next 'sPN oADoc.Update2(True) End Sub
Wesley Crihfield
(Not an Autodesk Employee)
Hi @Anders_Olsen. I had no idea what you were planning on doing with each component just after selecting them, but attempting to get them into a collection to then run some other iLogic rule on later was not on my radar. Using the SelectSet is usually not a good fit for something like that. It has some restrictions and can be a bit finicky. Using the other collection types (ObjectCollection, List(Of ), etc) should be OK though. However, if you need a means to capture multiple objects that will stay in place between running one rule, to running another rule, then some additional strategy would be required. There are ways for one iLogic rule to 'send' data to another iLogic rule, when it calls that other rule to run. And a way to 'receive' data back from the other rule, after the other rule has finished running, if both rules are set-up to do so. (RuleArguments) There is also a way to store data from one rule up into an Inventor 'session' memory variable, where later rule(s) can later access that data from (the uniquely iLogic SharedVariable). One of the restrictions of the SelectSet is that it can only 'select' things that exist within the 'context' (definition & model coordinate space) of the Document they are associated with. For example, the SelectSet from Document A can not select something that is within Document B. And if Document A is not the 'active' document, you will not be able to use the DocumentA.SelectSet.Select() method on anything in it anyways, because true selection only works on the 'active' document. I think that may be the problem in this case also, because some of the other components that may be referencing some of the referenced documents may be down within other sub assemblies, which means they would not be in the 'context' of the 'main/active' assembly directly. With that in mind, the SelectSet object that the SelectSet.Select() method being used in that last example I posted could be switched out for something like the List(Of ComponentOccurrence) type collection instead, which may enable it to capture all the components you want. However, I still don't know how your second rule will be using them, so still not sure if the context from where they are being gathered will be the best fit either.
When iterating through assembly components (instead of just referenced documents), and wanting to do so 'recursively' (keeps stepping down into lower levels on its own), there are two ways to do that, which each work differently, as far as 'context' is concerned. When stepping down through the 'definitions' of sub assemblies to access their sub components, that is one way, but the lower level components it accesses will not be in the 'context' of the main / active assembly. When stepping down through the ComponentOccurrence.SubOccurrences collection, the association with the parent 'context' is maintained, so that the lower level components are still in the context of the main / active assembly. This second way is sort of similar to navigating through the model browser tree's nodes, with the lower level nodes still being associated with the highest level node, due to the 'tree' structure. This second way sounds like what you likely need in your situation.
Within the example code that you posted above, I see a variable misspelling or difference in how it is spelled in multiple locations ("alreadyInList" vs "alreadyOnList"). It also looks like your variable named 'occList' may not be getting properly 'initialized'. When declaring a variable for a reference type between methods, we can not initialize it or set an initial value to it until it is accessed within one of the methods. It looks like you are using the 'New' keyword directly in the declaration line, then just adding values to it within the method, without first initializing the variable. The 'New' keyword is used to initialize the List object, before entries can be added to it, but that step should be done within the method, and only when it is encountered or the first time, so avoid resetting its contents. I also see that the 'assemblyRunner' method you are using, is also being used for 'recursion' down into lower levels of the assembly, but it is doing so through the 'definitions', which does not maintain contextual lineage with the 'active' assembly. That is not necessarily a good or bad thing, depending on what you are trying to do with those components later. If you are planning on making changes to those components later, then how you gathered them will determine the 'scope' (area of effect) of the changes. If gathered through their definitions, then changes will effect the independent referenced documents. If gathered through SubOccurrences properties, then changes may only be relevant to those occurrences from the perspective of the active assembly, depending on the types of changes. For example, if you wanted to change the colors of all components in an assembly, but do not want the color changes to actually effect the files that the components reference, but only want the colors to be in effect while viewing them from within the active assembly, then you would access them through the SubOccurrences property, instead of through their definitions.
Wesley Crihfield
(Not an Autodesk Employee)
Here is another example of the rule that just 'finds and collects' the components with matching Part Number values, but does not do anything else with them except 'sharing them' for a later rule or process to use. It is recursive, and broken up into 3 routines. The first routine gets user input, then calls the second routine to run, while supplying it with this assembly's components collection, and instructions about how they should be dealt with. Then the second routine is just for the recursion process, and should not need to be customized. Then the third routine is what actually does a custom task with each occurrence. In this case, that task is just getting the value of the Part Number iProperty from its referenced document, then seeing if that is one we are looking for. If so, add it to the List. Then, back in the 'Main' routine, after the recursion is done, it shares the List up into Inventor's session memory, so that a later rule can access it and do a custom task on its contents.
Sub Main Dim oADoc As AssemblyDocument = TryCast(ThisDoc.Document, Inventor.AssemblyDocument) If oADoc Is Nothing Then Logger.Debug("The iLogic rule named '" & iLogicVb.RuleName & "' exited, because no AssemblyDocument was obtained.") Exit Sub End If 'gather input from the user Dim sPartNumbersToFind As String = InputBox("Input part numbers separated by comma", "Select components") 'if nothing entered, or is empty, exit the rule If String.IsNullOrWhiteSpace(sPartNumbersToFind) Then Return 'attempt to put values into List If sPartNumbersToFind.Contains(",") Then oPartNumbersToFind = sPartNumbersToFind.Split(","c).ToList() Else If (oPartNumbersToFind Is Nothing) Then oPartNumbersToFind = New List(Of String) oPartNumbersToFind.Add(sPartNumbersToFind) End If 'get assembly occurrrences collection Dim oOccs As ComponentOccurrences = oADoc.ComponentDefinition.Occurrences 'call custom Sub routine to recurse this assemblies components 'True means maintain context with parent assemblies RecurseComponents(oOccs, True, AddressOf ProcessComponent) 'share the resulting List(Of ComponentOccurrence) object to Inventor's session memory SharedVariable.Value("FoundComponentsList") = oPartNumbersToFind 'a later rule can retrieve this by: 'Dim FoundOccsList As List(Of ComponentOccurrence) = SharedVariable.Value("FoundComponentsList") 'optionally update this assembly 'oADoc.Update2(True) 'optionally save this assembly 'If oADoc.Dirty Then oADoc.Save2(True) End Sub '<<< declare 'global' variables here >>> Dim oPartNumbersToFind As List(Of String) Dim oFoundOccs As List(Of Inventor.ComponentOccurrence) 'just for assembly component recursion process (no need to customize) Sub RecurseComponents(oComps As ComponentOccurrences, _ preserveContext As Boolean, _ ComponentProcess As Action(Of ComponentOccurrence)) 'validate input collection If (oComps Is Nothing) OrElse (oComps.Count = 0) Then Return 'start iterating input collection For Each oComp As ComponentOccurrence In oComps 'call custom task to run on this instance ComponentProcess(oComp) 'if this occurrence is suppressed, we can not iterate through its sub occurrences If oComp.Suppressed Then Continue For 'if this occurrrence is not an assembly, we do not want to iterate its sub occurrences If Not oComp.DefinitionDocumentType = DocumentTypeEnum.kAssemblyDocumentObject Then Continue For 'attempt to recurse down into its sub-components, if possible, and it has some If preserveContext Then '<<< edits (can be) constrained to context of 'parent' assembly >>> RecurseComponents(oComp.SubOccurrences, preserveContext, ComponentProcess) Else '<<< edit each component's definition &/or referenced file independently >>> RecurseComponents(oComp.Definition.Occurrences, preserveContext, ComponentProcess) End If Next 'oComp End Sub 'what to do to/with each occurrence Sub ProcessComponent(oComp As ComponentOccurrence) If (oComp Is Nothing) OrElse oComp.Suppressed Then Return 'skip virtual components 'If (TypeOf oComp.Definition Is VirtualComponentDefinition) Then Return 'skip welds within weldment type assemblies 'If (TypeOf oComp.Definition Is WeldsComponentDefinition) Then Return 'get referenced Document Dim oCompDoc As Inventor.Document = Nothing Try : oCompDoc = oComp.Definition.Document : Catch : End Try If oCompDoc Is Nothing Then Return 'get Part Number iProperty value Dim sPN As String = oCompDoc.PropertySets.Item(3).Item(2).Value 'if Part Number value is empty, then skip this component If String.IsNullOrWhiteSpace(sPN) Then Return 'if this is 'NOT' one of the Part Number values we are looking for, then skip it If Not oPartNumbersToFind.Contains(sPN) Then Return 'initialize the List, if necessary If (oFoundOccs Is Nothing) Then oFoundOccs = New List(Of Inventor.ComponentOccurrence) 'meeds our requirements, so add it to our List If Not oFoundOccs.Contains(oComp) Then oFoundOccs.Add(oComp) End Sub
Wesley Crihfield
(Not an Autodesk Employee)
As Marcin pointed out, the term "proxy" has been left out of our earlier conversations, but is very appropriate to include here, because it helps explain the whole 'context' thing, and why the selection will only work under certain conditions. They can be difficult to explain though. A proxy is essentially some geometry that has been (copied, moved, and reoriented) from within the context of a child level component in an assembly, up into the context of its parent assembly. The parent assembly can then select and interact with the proxy geometry, where it could not select or interact with the original geometry that existed in a different coordinate system. The concept of the ComponentOccurrence object itself is very similar to the idea of proxies, because it is also essentially a copied and transformed version of the geometry from within some other external file, that has been placed into the context of an assembly. Its geometry can be accessed by the assembly, as long as we are not stepping down into the definition of that component to access it. Proxies are often created/retrieved for the purposes of enabling measurements, constraints, and similar functionalities between the geometry of that proxy, and something else that is already in the appropriate context. Proxies are pretty much only necessary to work with and talk about when attempting to do things within assemblies by code, since Autodesk handles tons of these finer details for us automatically, behind the scenes, as we interact with things in the user interface. Even the 'Pick' method, which pauses a code to allow manual user selection of a single object, seems to do some stuff for us to help eliminate the need for dealing with proxies, because it always seems to return an object that is in the active document's context, even if that means that it had to create a quick proxy of it. The AssemblyComponentDefinition.AdjustProxyContext method seems to be one of the tools to help enable such interactions, along with the ComponentOccurrence.CreateGeometryProxy method. When we step down to lower level components using the ComponentOccurrence.SubOccurrences route, we are then accessing the proxies of those lower level components, which are still accessible by the parent level assembly (the assembly that directly contains the ComponentOccurrence object that the method is being called from). But when accessing lower level components through the ComponentOccurrence.Definition.Occurrences route, we are reaching down into a different document's coordinate space, breaking the connection to the parent level.
There are tons of official 'proxy' object Types, which are usually derived from the original object Type. If you go into the online help area, under the 'Programming Interface', then under 'Inventor API Reference Manual', then under 'Objects', and do Ctrl+F search for the text "Proxy", you will find around 270 object Types which include that term at the end of their names. That can be seen as an indicator of how important and widely used they are.
Wesley Crihfield
(Not an Autodesk Employee)
