iLogic / API get document of each model state without activation each of them

[dariuszm]

There should be an option to get each document object of each model state in model sates of part/assembly document without activation of each. Now to get each document you need to activate model state, and then you are able to get it. In that way it's takes more time to do something (because of display time).

[raymondxu]

Hi Dariusz,

Thanks for your idea. First let me explain some details in terms of time, then ask your further requirement in your mind.

Yes, it is possible to provide Inventor API to get each document object for each Model State. However, the time would be similar to switch one by one, or even slower. For example, one part has 10 Model States. We could offer an API to get 10 documents. In total, it is 10 document open time and 10 apply Model State override time. Inventor does not support in parallel open right now.

If I open this part in Model State1, and switch from 1 to 10, it is 1 document open and 10 apply Model State override time. 

However, if your idea is not just about time, but also about using multiple Model State documents at the same time, I can see the benefit.

And in assembly world, your idea has benefit to save time as well, because switching model state also has suppressed document closing time, but open is simply load and no document close.

[DRoam]

I'd really like for this to be implemented. I'd like for the "ModelState.Document" object to be something that I can just work with directly to query or modify a Model State's iProperties, Parameters, etc. without having to activate it. This has a huge convenience benefit.

But it's not just convenience. There's also the fact that, because I have to activate a Model State to work with it, that means I have to switch the active Model State just to READ the values of parameters/iProperties in a MS. That's a huge problem, because it turns even just READING information into an operation that dirties the document.

It also means you have to properly reset the active MS back to what it was originally after your iLogic/Add-In script is finished. This is easy to forget or could not get performed due to an upstream error. This could easily disrupt/confuse the user's experience or, worse, cause them to accidentally edit the wrong Model State because your script changed it from what it was when they last edited the part/assembly file.

I'm aware we can work with the MS table via the API but this is inconvenient and not practical in my opinion. It's not a good alternative to working with the API/object model that we're all so familiar with.

[raymondxu]

Thanks Derek. Modify is a different story especially parameters or features.

Current Model State capability is still offered on top of factory and member design. Factory is the editing environment to modify parameter or geometries, and is the single source of truth for all members. Members are generated (elaboration) from the factory. We can query Document.ComponentDefinition.IsModelStateFactory or Document.ComponentDefinition.IsModelStateMember to know model state document type.

In general we do not support modifying factory and member, or multiple members at the same time on both UI and API currently. Normally user need modify design in factory and elaborate member in consumption side (place in another assembly).

We do offer a special in-place editing environment in case user wants to modify member directly without factory loaded. Still only one member can be edited at the same time.

Further, considering customer might want to frequently change iProperties in multiple members, and iProperties does not impact much on geometry or shape recipe. We offer extra capability to modify multiple model state member iProperties at the same time directly through Document.PropertySets if this model state member Document is available.

ModelState.Document is a very special API object property. Essentially this aligns with UI design. Today in UI we do not offer a UI experience to directly open a Model State member. Everything user can see is in factory environment with one member active. This API is a convenient way for API user to access elaborated member documents.

In the future, it is possible we could allow user to modify anything could be captured in Model State Table directly in the Model State member document, e.g. parameters as Derek said. If such modifications are only required, I think we could consider it.

However, we will probably not support other modifications such as creation and deletion directly in multiple Model State member documents at the same time. We cannot allow to delete one feature in one member but not in other member, or even add a feature only in particular members.

[dariuszm]

There should be an object that can provide me all documents without activation of each model state. When you do something on each document (with activation) now you need to disable screen refresh and visibility.

[DRoam]

Hi Raymond, thanks for the detailed reply! That  helps clarify things with the factory vs. “elaborated” member documents. And I think you’ve captured it well — being able to change the things we can normally change in the UI via the API is what I’m after and would be great. Certainly not asking to be able to create new features from the member document or modify multiple member documents at once. We would handle that via iteration.

This is much like what we can do in the BOM today, editing the iProperties of whatever members we can see, even though they’re not necessarily the active member in the factory. It would be great to do the same thing, via the API ModelState.Document object, for iProperties, parameters, suppression, and whatever else can be supported. 

Thanks!

[raymondxu]

Both your requirements are well understood.

Dariusz, let me share current approach to modify any model state without activate each model state, and see whether your requirements are satisfied.

Let me list your possible requirements first,

1) suppress feature, modify parameter (or other operations...) for current active model state

2) suppress feature, modify parameter (or other operations...) for other non-active model state

3) suppress feature, modify parameter (or other operations...) for all model states

Any other possible operations that I miss?

Here is current approach.

For 1), this is easiest one that we can just directly access ThisApplication.ActiveDocument.ComponentDefinition, read or modify objects.

For 2), we will be able to access ThisApplication.ActiveDocument.ComponentDefinition.ModelStates.ModelStateTable, read or modify cell values for the model state that ModelStateTableRow represents. For example, I want to suppress part Extrusion1 feature in MS1. My current active is MS0. I can go to ModelStates.ModelStateTable.TableRows.Item("MS1") and modify the cell represents Extrusion1 suppression to be "Suppressed". This plays the same role as switching to MS1, go to ComponentDefinition.Features.ExtrudeFeatures.Item("Extrusion1") and modify Suppressed status.

For 3), there is no need to switch at all. please first set ModelStates.MemberEditScope as kEditAllMembers, and modify object in ComponentDefinition or properties...

Besides, there are still operations cannot be member scope, for example deleting feature, or any sketch geometry operations. We can just operation PartComponentDefinition in current active Model State. This should just impacts on all model states.

Hope this is useful.

[C-Hoppen]

👏

[raphael.widmann5DUKP]

Hello raymondxu,

Is this Idea implemented already? If yes:

you wrote: "I can go to ModelStates.ModelStateTable.TableRows.Item("MS1") and modify the cell represents Extrusion1 suppression to be "Suppressed"."

Can you give a Code example, to acces a value of a cell at a ModelStateTable, so how to "modify" practically?

Thank you in advance and beste regards
Raphael

[dan_szymanski]

This idea has been implemented within Autodesk Inventor 2025. Please review the Inventor 2025 What's New article here, for more information regarding how you may leverage this enhancement. Special thanks to everyone who cast a vote for it.