Issue with Model States and IsModifiable

[nmunro]

I'm seeing some unexpected behavior with the IsModifiable property when modifying property values in a model state document that is a occurrence in a higher level assembly. The basic structure of the assembly is shown in the following image.

When the top level assembly is loaded, the Assy1 document has its  IsModifiable property set to True. A change is made to a property value in either the Master (currently testing in IV2022) or one of the custom model states (the Substitute model state assembly cannot be modified). This change works  as expected and the file(s) can be saved.

In doing this, the IsModifiable property for the Assy1 document is set to False. However, this is not correct as another property edit can be completed without issue. No amount of saving will reset the value to True. If the Assy1 file is opened in its own window, the IsModifiable property of  the assembly is True. The only way to reset the value of the Assy1 occurrences in the Top Level Assy is to close and reopen the Top Level Assy file.

Is this an IV2022 known issue or will I expect to see the same issue in later Inventor versions?

Edit: The active interop assembly is 26.2.0.0

[YuhanZhang]

@nmunro In your data, the top assembly references to several model states of the Assy1, that means in memory you may access different model state member documents of Assy1, and when you try to edit the properties in Assy1 you might try to edit different model state member documents(and/or model state factory document) of Assy1, and we don't allow to edit a model state member(or factory) document if another model state member(or factory) document in the same assembly/part is dirty, this is to avoid edit confliction.  To solve this "issue" you can check the Document.IsModifiable and if it returns False you can call Document.Update to accept the edits in another model state member(or factory) document to all model state member(or factory) documents, and then you can edit current document.

[nmunro]

Hi Rocky,

Thanks for the quick reply. I see the logic of this but calling Document.Update() after completing the property update does not change the IsModifiable flag. Is it required to call Update on the factory document perhaps to ensure the MS table is updated? Also, the RequiresUpdate property of the document reports false just prior to calling the Update method. 

Edit1: If I do recover the factory document, its IsModifiable property is set to true while the Document itself says false. An update on the factory document does not flip the IsModifiable property for the Document object.

Edit2: I tried iterating over all the states and updated both the member and factory documents. Still the same result.

Neil

[YuhanZhang]

@nmunro Sorry, I fogot to mention that another rule for this case in Inventor 2022 is, if both the model state factory document and model state member documents are opened in memory, you need to only edit the model state factory document. If only the model state member documents are opened in memory then you can edit one model state member document and then switch to another model state member document and call Document.Update to make sure you can edit this member document. 

In your code you can check Document.ComponentDefinition.IsModelStateMember, if this returns True then try to get the Document.ComponentDefinition.FactoryDocument, if you can get the model state factory document then you edit it instead of model state member document, after editing the model state factory document you iterate all its model state member documents and call Update to make sure they are up-to-date.

[nmunro]

Hi Rocky,

Hmmm, this doesn't seem to match what I am seeing.

My  first question is what happens from a UI perspective when a user right-clicks a MS occurrence and invokes the iProperties command. On saving any changes, is the factory document accessed and edited, and then all member documents of all other MS in the document are accessed and updated? 

In my add-in I can change the same property on multiple occurrences that are different MSs from the same document without accessing a specific factory or member document. I assume (will test this) that by getting the Document associated with the occurrence I get a reference to the member document. Applying the change to the property updates the value in each of MSs without having to call any update in between. Saving the top level file saves the changes to MS documents as expected. 

When you save a document with edits to multiple MSs within that document, should that not ensure that all MS documents within are up to date? If so the Document.IsModifiable flag should be reset to True.

[YuhanZhang]

@nmunro Can you try to run below VBA code to check if the model state factory document is opened or not in the case 1): you can edit one model state member document;  case 2) :you can't edit any model state member document

Sub printInfo()
    Dim oDoc As Document
    For Each oDoc In ThisApplication.Documents
        
        If oDoc.ComponentDefinition.IsModelStateFactory Then
            If oDoc.Open Then
                Debug.Print oDoc.FullDocumentName
            End If
        End If
    Next
End Sub

Pleae note that when we talk about a document is opened means the document is not only initialized, where the Document.Open property will indicate this. For the two cases when you run the VBA code, you can see that when you are able to edit a model state member document(whose Document.IsModifiable = True) then its factory document is not opened in memory; while if you can't edit any model state member document then its factory document should be opened in memory. 

Please let me if see different cases. 

[nmunro]

Hi Rocky,

I'm not 100% sure of what you are after but I performed two tests.

1. Opened the top level assembly.. Immediately ran your VBA macro. No documents reported open.

2. Used my app to edit property values in the Master and Custom Assy1 documents. No Document.Update calls were made and there was no explicit activation of the factory document for either of the referenced MS docs. The Assy1.ComponentDefinition.IsModelStateFactory is true  and the name of the document is printed. 

I do have a video of what I am seeing but I would rather not post it here. Can I send it to you?

Neil

[YuhanZhang · Accepted solution]

Hi Neil,

Some UI or API operations may cause the Assy1's model state factory document to be loaded(i.e. Document.Open = True), then you can't edit any model state member document from this assembly, you need to edit the model state factory document instead.  I am not sure what you may do in UI or your app, but seems the Assy1 model state factory is opened during your work flow, so to make your code robust, you need to check if the model state factory document is opened or not for each time you want to edit a model state member document, once the model state factory document is opened already you can switch to edit factory document.

[nmunro]

Sorry for the short reply last evening.

I see that a hidden factory document is always loaded when a document with multiple MS is placed as an occurrence in an assembly. If there are 3 different MS occurrences, there a 4 documents "opened", the three member documents and the factory document from the master MS. Due to the structure of my app it might be better to write changes directly to the model state table even though it is not required in this workflow. If so, would this still require Update to be called on all MS member documents?

[YuhanZhang]

Hi Neil,

Usually if you just place a sub assembly as occurrences(using Occurrences.Add) it won't load the sub assembly's model state factory document. If in your code after placing the occurrences you see the model state factory document is loaded(i.e. Document.Open = True), we need to check if you do something more in your code that caused the factory document to load.

After you edit model state factory document, you may still have to call the Document.Update for a model state member document, so if you need to use model state member document you can check if the Document.RequiresUpdate = True, if it is True you can call Update firstly before  using it.

[nmunro]

Hi Rocky,

Thanks, I'm getting a better understanding. The app deals with properties only so no occurrence placement. It seems any change to the document (I have to access MassProperties) causes the factory document to open. Anyway, thank you for the information and I think it can be sorted.

In IV2023.2 and later you can now edit MS documents in-place, does that functionally change any of this?

Neil

[YuhanZhang]

Hi Neil,

Inventor will try to not load the factory document as far as possible, when you do in-place edit it is to edit the model state member document, so ideally it should not load the model state factory document.