Announcements
Attention for Customers without Multi-Factor Authentication or Single Sign-On - OTP Verification rolls out April 2025. Read all about it here.
WCrihfield
in reply to: e_jeanUH6EY

Hi @e_jeanUH6EY.

This is one of those situations that almost needs a university course paper to properly explain or describe.  The ModelState object has two Properties for Document Type objects (ModelState.Document & ModelState.FactoryDocument), and both are ReadOnly, which just means you only 'get' their value, but can not 'set' another Document as their value.  The Property named "FactoryDocument" is supposed to return a Document object that is associated with the 'active' ModelState in that File.  However, if accessing that Property of the 'active' ModelState, it will not have a value (it will be Nothing).  A 'File' will only have a ModelState 'factory' Document, if it has more than just the one, original ModelState in it.  If a File has a 'factory' Document, then that is the only one you can make direct changes to, and is the one you must access the other ModelStates related resources through, to make changes to them.  The ModelState Property simply named "Document" is supposed to return the 'member' Document that is associated with that ModelState.  However, this property will also not have a value (will be Nothing), if that ModelState has never been referenced by an assembly component occurrence before.  When you place an assembly component occurrence into an assembly, set to a specific custom ModelState version of the File it references, that action automatically generates the 'member' Document for that ModelState, if it did not already exist, and may update the existing member Document, if it already existed.  But we usually can not directly edit a ModelState 'member' Document (but can read data from it, if it exists).

 

So, if we need to make changes to a ModelState member Document, we must do one of the following things:

  • If working with a part or assembly directly, while it is the 'active' Document (visibly showing on your screen at that moment), then:
    • You can simply activate the ModelState that you want to make changes to
    • Then make sure you have a reference to the Document associated with that newly active ModelState
    • Then make those changes to that Document
  • If working working with a part or assembly remotely (a referenced Document in the background, not the 'active' one), then:
    • We need to find out if that File has multiple ModelStates in it (or has a 'factory'), and if so, get a reference to that factory document first.
    • If you need to 'create' any new UserParameters, or custom iProperties, or new features, you can do so within this factory document, and they will also exist for all other ModelState versions, either with the same initial value, or no value (a parameter must have a value, but a property can have an empty value).  A new feature may be suppressed in all other ModelStates.
    • If you want to change values of existing parameters, properties, or suppression statuses, then you can do that within the ModelStateTable, which is accessed from the ModelStates.ModelStateTable property.  But that table will only exist if there is a ModelState factory, and you are accessing that property from through factory document.  The ModelStateTable can be navigated by its rows & columns.  Each row represents a ModelState member, and each column represents something like a parameter, iProperty, suppression status of a component occurrence, suppression status of a feature, or something like that.  Each column will have a heading indicating what that column is for.  The cell at the intersection of a row and column will have a String type value that is Read/Write, which you can change the value of.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)