Hi @G60Dubs. One small change you can try would be to switch which line of code is commented vs uncommented, between Lines 19 & 20. They both work very similarly in many scenarios, but both can also cause different results in some scenarios. It has to do with context. Line 20 is maintaining 'lineage' from the main assembly, while Line 19 breaks that lineage every time it steps into a different ComponentDefinition, where it is effectively editing other documents internally, instead of just assembly level settings from the perspective of the main assembly. I was not 100% sure about your exact intent with this process.
Also, keep in mind that it is the job of the ModelStates to record suppression status changes. And there is at least one ModelState in every model document, unless it is something like a Content Center member, iPart/iAssembly member. So, suppression was intended to be recorded at each level, by the ModelState in that model file, then when you place that model into an assembly, as an assembly component, you should set the ModelState of that assembly component to one of the ModelStates that exists within that the model file that the component references. Then that component's ModelState setting is recorded by the ModelState that was active in the assembly at the time you placed that assembly component directly into. Then when you place that assembly into another assembly, as an assembly component, you would that component to one of the ModelStates that is available within the model file it is referencing, and so on. This process was meant to be set-up from the bottom level, up to the next level, then up to the next level, and so on, not from the top level, then working its way down. A ModelState in an assembly can only keep track of the components that are directly placed with it, and not any of the sub components. Those sub components are managed by the ModelStates within the sub assemblies.
Also, when there are two or more assembly components within the entire structure of the assembly that reference the same file on disk, but different ModelState version of it, then the first instance the code encounters may act normally (Read/Write), but the next instance it encounters will most likely act like (ReadOnly), so nothing will happen to it. We are supposed to be able to update the main assembly between working on the first instance and working on the second instance, to make the second instance become Read/Write again, but that is not always convenient or efficient when working on a huge assembly.
Below is a link to an online help article which points this issue out.
https://help.autodesk.com/view/INVNTOR/2024/ENU/?guid=GUID-418B956A-AC3F-48D8-BEBC-FC28C4B51DA2
My guess is that you would have to create one or two special ModelStates within each sub assembly that contains any iPart members or content center members, in which those types of components are suppressed. Then set the component representing those sub assemblies to one of those special ModelStates at each level of the overall assembly structure, instead of trying to control all suppression at all levels of the whole assembly at one time, without using the ModelStates along the way.
Wesley Crihfield
(Not an Autodesk Employee)