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

Based on that recap and what you said at the end of 'Message 5', my best guess is that there is a bug preventing us from running local rules (or all rules effecting that document) while a ModelState other than "Master" is active.  It kind of sounds familiar...like I've heard about this before somewhere, but I can't remember where.  May have been a webinar or something about the current limitations of ModelStates.  And it also seems to be blocking your simple call to set the value of the parameter while a ModelState other than "Master" is active.  I know that non-Master ModelStates have a table in them that can be edited, similar to an iPart, iAssembly, or iFeature table, that can be edited like a spreadsheet (with Excel or whatever native editor you have).  And I know that the ModelStates object has a MemberEditScope property that needs to be set to specify whether changes effect all ModelStates or just the 'active' ModelState.  But I honestly have not tried this specific task before yet.

 

Here's a thought as we explore this idea.  I bet we have to first set the MemberEditScope setting to "kEditActiveMember" (without quotes).  Then either edit the table, or dig down into the ModelState.FactoryDocument, then into its ComponentDefinition.Parameters.Item("parameter_name").Value to get/set its value only for that one ModelState, when dealing with a Parameter.  Similar process for suppressing or un-suppressing a feature only in that one ModelState.  Using the API route would look like oModelState.FactoryDocument.ComponentDefinition.Features.Item("feature name").Suppressed = True.  We may have to do all of this from that main rule in the assembly, instead of using that local rule within the part document.  I'm not 100% sure, though.  The process I just stated makes better/clearer sense to me right now though.  If we were to edit the table, it might get more complicated, because we won't know how its all laid out to find stuff within, so we would likely have to use a series of loops through rows & columns to find the right cell values to change.

 

PS.  I tested that route on a test assembly and it works.  (Digging down into the FactoryDocument to get the Parameters & Featrues, that is.)

Wesley Crihfield

EESignature

(Not an Autodesk Employee)