Community
Inventor Programming - iLogic, Macros, AddIns & Apprentice
Inventor iLogic, Macros, AddIns & Apprentice Forum. Share your knowledge, ask questions, and explore popular Inventor topics related to programming, creating add-ins, macros, working with the API or creating iLogic tools.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How do I change Model State representations of occurrences in an assembly?

5 REPLIES 5
SOLVED
Reply
Message 1 of 6
f_calebh
728 Views, 5 Replies

How do I change Model State representations of occurrences in an assembly?

f_calebh
Advocate
Advocate

I'm struggling to create  configuration code to change occurrence model states based on various assembly conditions. I've started with a pretty straight forward "Traverse Assembly" loop to change a specific occurrence based on the Occurrence Name, but I'm not sure what I need within it to actually modify the occurrence's model state. I feel like I need more than my line 17 snippet... Any help would be appreciated. Thanks.

 

Sub Main
    ' Get the active assembly. 
	Dim oAssyDoc As AssemblyDocument = ThisApplication.ActiveDocument 
	
    ' Call the function
    Call TraverseAssembly(oAssyDoc.ComponentDefinition.Occurrences)
End Sub 
 
Sub TraverseAssembly(oOccs As ComponentOccurrences)
    ' Iterate through all of the occurrence in this collection
	Dim oOcc As ComponentOccurrence
	For Each oOcc In oOccs 
		

	' Random conditional for testing purposes
		If oOcc.Name = "OccurenceName" Then
			oOcc.ActiveModelState = "ModelStateName"
		End If
	

		' Recursively call sub if needed
		If oOcc.DefinitionDocumentType = kAssemblyDocumentObject Then
			Call TraverseAssembly(oOcc.SubOccurrences)
		End If
	Next
End Sub

 

 

0 Likes

How do I change Model State representations of occurrences in an assembly?

I'm struggling to create  configuration code to change occurrence model states based on various assembly conditions. I've started with a pretty straight forward "Traverse Assembly" loop to change a specific occurrence based on the Occurrence Name, but I'm not sure what I need within it to actually modify the occurrence's model state. I feel like I need more than my line 17 snippet... Any help would be appreciated. Thanks.

 

Sub Main
    ' Get the active assembly. 
	Dim oAssyDoc As AssemblyDocument = ThisApplication.ActiveDocument 
	
    ' Call the function
    Call TraverseAssembly(oAssyDoc.ComponentDefinition.Occurrences)
End Sub 
 
Sub TraverseAssembly(oOccs As ComponentOccurrences)
    ' Iterate through all of the occurrence in this collection
	Dim oOcc As ComponentOccurrence
	For Each oOcc In oOccs 
		

	' Random conditional for testing purposes
		If oOcc.Name = "OccurenceName" Then
			oOcc.ActiveModelState = "ModelStateName"
		End If
	

		' Recursively call sub if needed
		If oOcc.DefinitionDocumentType = kAssemblyDocumentObject Then
			Call TraverseAssembly(oOcc.SubOccurrences)
		End If
	Next
End Sub

 

 

5 REPLIES 5
Message 2 of 6
WCrihfield
in reply to: f_calebh

WCrihfield
Mentor
Mentor
Accepted solution

Hi @f_calebh.  You may have to explain in a little more detail about what you are trying to do with the code so we can offer better quality help.  Does your main assembly itself also have more than just the one original ModelState?  If so, you could set each component's ModelState to where you want it, and that will be recorded within the 'active' ModelState of the main assembly (or all of them if MemberEditScope is set to factory scope).  Then you could switch to a different ModelState of your main assembly, then set the components to a different variation of their ModelStates, and those settings will be saved within the assembly's active ModelState.  Then you can simply switch back and forth between the main assembly's ModelStates to switch all of the components ModelStates to the way you want them.  That is just a broad plan that could be used, if it fits your needs.  Also, keep in mind the difference between using ComponentOccurrence.SubOccurrences vs ComponentOccurrence.Definition.Occurrences as what you are supplying to the traverse assembly routine.  When using the SubOccurrences route, you are essentially staying in the scope of the main assembly, but when using ComponentOccurrence.Definition.Occurrences, you are effecting the sub assembly documents.  Just so you know.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

0 Likes

Hi @f_calebh.  You may have to explain in a little more detail about what you are trying to do with the code so we can offer better quality help.  Does your main assembly itself also have more than just the one original ModelState?  If so, you could set each component's ModelState to where you want it, and that will be recorded within the 'active' ModelState of the main assembly (or all of them if MemberEditScope is set to factory scope).  Then you could switch to a different ModelState of your main assembly, then set the components to a different variation of their ModelStates, and those settings will be saved within the assembly's active ModelState.  Then you can simply switch back and forth between the main assembly's ModelStates to switch all of the components ModelStates to the way you want them.  That is just a broad plan that could be used, if it fits your needs.  Also, keep in mind the difference between using ComponentOccurrence.SubOccurrences vs ComponentOccurrence.Definition.Occurrences as what you are supplying to the traverse assembly routine.  When using the SubOccurrences route, you are essentially staying in the scope of the main assembly, but when using ComponentOccurrence.Definition.Occurrences, you are effecting the sub assembly documents.  Just so you know.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

Message 3 of 6
f_calebh
in reply to: WCrihfield

f_calebh
Advocate
Advocate

@WCrihfield, there are no additional Model States within the Main Assembly. The conditional changes are based on the product's size, which is custom (width and height), so I won't be able to have static states based on sizing. Instead, I already have code for adjusting the sizing parameters for all assembly "references". These Parameter changes aren't used specifically in any of the Model States, so I change them with the EditAllMembers scope on. I can show this code if you'd like to see it as well.

 

This second configuration code is going to be based on specific size "Ranges". Components may need to be represented by a different Model State depending on its overall length. I haven't written those conditions in yet because I want to get a simple Model State change working before I get too deep on the conditions.

 

I had assumed that the SubOccurrences of an Occurrence from the Main assembly would parse through all the sub-assemblies. I'll look into that some more. Thanks for the info. The loop seemed to be working fine when I was testing with a Show MessageBox function instead of trying to change a Model State.

0 Likes

@WCrihfield, there are no additional Model States within the Main Assembly. The conditional changes are based on the product's size, which is custom (width and height), so I won't be able to have static states based on sizing. Instead, I already have code for adjusting the sizing parameters for all assembly "references". These Parameter changes aren't used specifically in any of the Model States, so I change them with the EditAllMembers scope on. I can show this code if you'd like to see it as well.

 

This second configuration code is going to be based on specific size "Ranges". Components may need to be represented by a different Model State depending on its overall length. I haven't written those conditions in yet because I want to get a simple Model State change working before I get too deep on the conditions.

 

I had assumed that the SubOccurrences of an Occurrence from the Main assembly would parse through all the sub-assemblies. I'll look into that some more. Thanks for the info. The loop seemed to be working fine when I was testing with a Show MessageBox function instead of trying to change a Model State.

Message 4 of 6
WCrihfield
in reply to: f_calebh

WCrihfield
Mentor
Mentor

OK.  I don't really see anything wrong with the code you posted, I just was not sure what was expected.  Line 17 is definitely the normal way to set/change which ModelState the component is representing.  You just have to make sure that that a ModelState with the name you specify actually exists within the file being referenced by that component, otherwise it may throw an error.  Also, if you are going to be processing components by their names, it may be a good idea to 'stabilize' the component names in the assembly ahead of time, by renaming them differently than their default names.  That way, if you replace any components, or use save/replace, or copy design type techniques, the code will keep working OK after the changes (the component's name won't change).  Also, if you have any of your components suppressed, you may need to add a line of code to avoid trying to change those, because that will likely cause an error.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

OK.  I don't really see anything wrong with the code you posted, I just was not sure what was expected.  Line 17 is definitely the normal way to set/change which ModelState the component is representing.  You just have to make sure that that a ModelState with the name you specify actually exists within the file being referenced by that component, otherwise it may throw an error.  Also, if you are going to be processing components by their names, it may be a good idea to 'stabilize' the component names in the assembly ahead of time, by renaming them differently than their default names.  That way, if you replace any components, or use save/replace, or copy design type techniques, the code will keep working OK after the changes (the component's name won't change).  Also, if you have any of your components suppressed, you may need to add a line of code to avoid trying to change those, because that will likely cause an error.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

Message 5 of 6
f_calebh
in reply to: WCrihfield

f_calebh
Advocate
Advocate

Thanks, I'm still getting an unspecified error with it. I checked the names and they seemed to be correct. Unfortunately, I'm not able to share this particular assembly, so I'll see if I can recreate my problem in something shareable.  

0 Likes

Thanks, I'm still getting an unspecified error with it. I checked the names and they seemed to be correct. Unfortunately, I'm not able to share this particular assembly, so I'll see if I can recreate my problem in something shareable.  

Message 6 of 6
f_calebh
in reply to: f_calebh

f_calebh
Advocate
Advocate

Update. I DID have a spelling error.  Doh! That will send you down a rabbit hole!

 

The solution was as you mentioned in your first response. Switching to ComponentOccurrence.Definition.Occurrences in my recursive call was all I really needed to update.


Update. I DID have a spelling error.  Doh! That will send you down a rabbit hole!

 

The solution was as you mentioned in your first response. Switching to ComponentOccurrence.Definition.Occurrences in my recursive call was all I really needed to update.


Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report