ModelStates with iLogic requires Update after Save

[J-Camper]

I'm trying to figure out what to correct/change some iLogic conrtol to avoid this weird update after save issue I'm seeing in Parts/Assemblies which use modelstates and get sized with iLogic.  I created a simple example, which is attached and shows the glitch in the video below:

I have found that if you have multiple files with i logic controlling them in a larger assembly, only the last one modified gets the update glitch.  I have also found that you can clear this issue by going into the affected modelstate, perform combination of save, update, change to a different modelstate, and change back.  Then the Save nolonger makes the document think an update is needed.  See different example and fix below:

Is there something I can add/change in the iLogic rule so that I don't need to go into the document to get it to update properly?

[J-Camper · Accepted solution]

I created a work-around for this.  It is an iLogic rule set on the Global Event Trigger "After Save Document" for Parts and Assemblies.

Sub Main
	Dim doc As Document = ThisDoc.Document
	If Not doc.RequiresUpdate Then Exit Sub
	If Not doc.IsModifiable Then Exit Sub
	If doc.DocumentType = DocumentTypeEnum.kAssemblyDocumentObject
		If doc.ComponentDefinition.FactoryDocument Is Nothing Then Exit Sub
		ToggleMSDoc(doc)
	Else If doc.DocumentType = DocumentTypeEnum.kPartDocumentObject
		If doc.ComponentDefinition.FactoryDocument Is Nothing Then Exit Sub
		ToggleMSDoc(doc)
	End If	
End Sub

Private Sub ToggleMSDoc(AssemblyOrPart As Document)
	Dim ReturnMS As ModelState = AssemblyOrPart.ComponentDefinition.ModelStates.ActiveModelState
	Logger.Trace("ModelState Document Requires Update After Save: """ & AssemblyOrPart.DisplayName & """")
	For Each MS As ModelState In AssemblyOrPart.ComponentDefinition.ModelStates
		If MS.Name Is ReturnMS Then Continue For
		MS.Activate()
		Exit For
	Next
	ReturnMS.Activate()
	AssemblyOrPart.Save()
End Sub

I wish it was something that Inventor could resolve itself, but this seems to work pretty well in my test documents so far.

[Curtis_Waguespack]

@J-Camper , I just took a look at your assembly, and I see the same results.

@MjDeck can you tell us what is going on here, this doesn't seem like the correct behavior

[MjDeck · Accepted solution]

Thanks @J-Camper for reporting this. And thanks @Curtis_Waguespack for bringing it to my attention. It is a bug. I created internal issue INVGEN-84222.

The problem won't happen if you take out this line from the assembly rule:

iLogicVb.MemberEditScope = MemberEditScopeEnum.kEditActiveMember

The rule will work the same without it. But maybe you need that line because elsewhere in your larger model you're setting the scope to kEditAllMembers.

Here's another workaround. This one does not require an event trigger. Change the assembly rule to this:

Sub Main
iLogicVb.MemberEditScope = MemberEditScopeEnum.kEditActiveMember

Parameter("simplePart:1", "length") = Parameter("feed_length")
Parameter("simplePart:1", "width") = Parameter("feed_width")
Parameter("simplePart:1", "thickness") = Parameter("feed_thickness")

UpdatePartComponentFactory("simplePart:1")

iLogicVb.UpdateWhenDone = True

End Sub

Sub UpdatePartComponentFactory(componentName As String)
	Dim compOcc = Component.InventorComponent(componentName)
	Dim def As PartComponentDefinition = compOcc.Definition
	Dim factoryDoc = def.FactoryDocument
	factoryDoc.Update()
End Sub

That could be extended so it would work for subassemblies as well.

Note that it uses UpdateWhenDone instead of DocumentUpdate. That's to make sure that the update runs after the rule has finished. It's generally a safer way to do an update.

[J-Camper]

Thanks for looking into this @MjDeck. 

I recently upgraded from 2023 to 2025 and thought I needed the MemberScope line in assemblies which use multiple ModelStates of the same document. 

It looks like as long as the sub-assemblies utilize your workaround in their local rules, then the larger end user level assemblies won't need it.  I do like your workaround more since it does not rely on a save, but it will require modifying code in all my standard sub-assemblies, and any that have been copied off for real project applications. 

Thanks for the tip about UpdateWhenDone too.  I wasn't aware it was safer then the DocumentUpdate.  I will transition my usage where I can, when an immediate update is not needed.