Breakdown of the differences between `FactoryDocument` and Document returned from `Application.Documents.Open`?

[Anonymous]

Hi

We have some logic that enforces standards in our models, that's run from anywhere from parts to assemblies to drawings; for instance, just before an assembly is saved, we automatically check certain properties for compliance, in the assembly itself as well as each sub-document.

I'm trying to optimize some of our processes. One thing I'm looking to eliminate if I can is our calls of `Application.Documents.Open`, which runs in the above example at the start to gather each document to be operated on. My understanding is that this might be replaced by simply using the `FactoryDocument` from the `ComponentOccurrence.Definition.Document.ComponentDefinition`;

however, simply swapping this out, from a call to `Application.Documents.Open` to a check to see if the `Document` is a model state factory and returning it as-is, if not, or the `FactoryDocument`, if so, doesn't seem to go so smoothly:

There are at least two errors that wouldn't otherwise exist: the first is deleting material assets local to the target document; the second is renaming its model states.

Can anyone account for this difference in behaviour? Are there other differences that have been encountered or documented somewhere I should be aware of?

Thanks

[WCrihfield]

Hi @Anonymous.  There are certainly lots of new odd behaviors when ModelStates are involved, especially when it comes to attempting to make changes to multiple components within an assembly, from the top level assembly, and some of those components may be representing the same base file on disk, but different ModelStates.  As you may know, when you load an assembly, it also loads the assembly's referenced documents into memory in the background, if tshey are not currently suppressed.  That means there may be multiple ModelState versions of the same part open in Inventor's session memory.  When working from the top level assembly, all of those components that have multiple ModelStates, will be understood as representing ModelState 'member' documents, even if there are only two ModelStates for the one component, and both are represented by different components.  And in order to be able to make changes to the second component, based on the same file, but set to a different ModelState, you must update the next one first before attempting to make the changes.  This is just one of the odd new quirks I have found out about.  The factory document is simply the Document that represents the file's active ModelState.  One of the best ways I have found to identify which version document you are currently working with is to check the Document.FullDocumentName, because that will start with the FullFileName, but then include the name of the ModelState that it represents at the end like "<ModelState1>", when there are more than one possible ModelState.  There are also several little helpful utilities related to ModelStates under the Autodesk.iLogic.Runtime reference, which is already automatically included for us in iLogic rules.  If you just need to Read or check data in a Document, it does not need to be the factory document.  But if you need to be able to make changes to the document, and it is not currently the factory document, you may need to cause it to be the factory document, by 'activating' the ModelState that it represents.  I have see situations where attempting to activate a ModelState or change the MemberEditScope status remotely will cause an error, and if that is the case, you may be able to change things like already existing Parameters, iProperties, feature or component suppression, by getting the ModelStateTable from the factory document, then editing the Cell values within that.  This will allow changes to every ModelState in the file in one place, but it will not allow you to add more columns to the table for new things.  Or you can edit the ModelStates by Excel using the ModelStates.ExcelWorkSheet.