Running iLogic rules within model states

[ndillner343SKL]

I'm trying to run rules (that change parameters) within sub assemblies / components that contain model states. I found that in order to do so where I'm launching the rule needs to be the only document open. All sub components need to be closed. 

But if the rule was to run with a sub component open I find that it breaks the model. Specifically a sub component with model states. What I mean by breaks the model is that, it wont run the rule for that component since the model is open but even after the sub component model is closed when immediately trying to run the rule again the sub component will not update.  

I found that using 

ThisDoc.Document.Save2()

within the code helps, but its not perfect.  Anyone know how to keep to lower level assemblies/components that contain model states from breaking when running code?

[WCrihfield]

Knowing what that other rule ("Master Rule") does may help in answering this question.  Also, in an assembly, all those sub assemblies and components within are already considered either open or initialized while the main assembly is open, so you wouldn't need to bother opening and closing any of them anyways, unless maybe the main assembly is in express mode or something like that.  Same goes for drawings...the models shown within the drawing are considered either open or initialized while the drawing is open.  Initialized documents will automatically be fully opened any time you try to access something about them that requires them to be open.  But you still don't have to close them unless you've visibly opened them.

One of the most common issues has to do with properly identifying and specifying which document your code is supposed to be acting on or accessing.  I wrote a contribution post about some of the most common document references used in iLogic rules and what they actually point to in different situations.  Many of the iLogic snippets will attempt to target or use the 'active' document, if you don't include a document or component in the line of code for it to act on.

There are also two sets of methods for running iLogic rules.  One set is at that iLogicVb (ILowLevelSupport) level, the other set is after iLogicVb.Automation (IiLogicAutomation).  The methods in that second level allow you to supply an actual document object, instead of just an ambiguous name.  When running rules this way, you could even use one of the methods that allow you to supply 'arguments' ('with arguments' version), then one of the things you could send to the rule in the NameValueMap (say if it were an external rule) is the document object you want it to act upon.  If you did that, you would have to also prepare that rule it is to run, so it will be able to receive the data (or document) you are sending to it.  The main component for doing this on the receiving end is the RuleArguments object.  Here is a link to a contribution post showing this in action, if that interests you.

If this solved your problem, or answered your question, please click ACCEPT SOLUTION.
Or, if this helped you, please click (LIKE or KUDOS) 👍.

If you want and have time, I would appreciate your Vote(s) for My IDEAS 💡 or you can Explore My CONTRIBUTIONS

[ndillner343SKL]

The "Master Rule" is pulling values from an excel sheet to the parameters. I've attached the models I've been using to demonstrate.

Within the demonstration models linked below I receive an error when attempting to run the code while the "Box.ipt" is open and unless I add the ThisDoc.Document.Save2 that error would continue even after closing "Box.ipt". 

I appreciate you're response! I'll dive deeper into the "Automation" & "contribution post" and see if that has any effect.

Thanks!

[WCrihfield]

I wrote about a similar related observation in your other post too...

https://forums.autodesk.com/t5/inventor-ilogic-api-vba-forum/api-pulling-user-parameters-within-a-su...

But I have another observation to report about a scenario within the files in your ZIP file.

I created a new local rule within both of the part files, simply named "Rule1" (same rule code and rule name in both parts), and is simply contained:

MsgBox("FullFileName = " & ThisDoc.Document.FullFileName, vbInformation, "iLogic")

to display the full file name of that local part when the rule is ran, just as specifically identifiable feedback to confirm whether or not the rule is being found & ran.  Then I created a new rule within the main assembly called "Run Rule1 In Component", and it simply contains the following line of code to run the rule in the component:

iLogicVb.RunRule("Box1:1", "Rule1")

 Now, when I run this rule in the assembly, it fails, and keeps failing when tried multiple times in a row.

However, when slightly change the component name to the second occurrence of the same part "Box1:2" then run this rule, it succeeds, and keeps succeeding when ran multiple times in a row.  Since both components represent the same Part, this doesn't seem right, so I did some further investigation and found something.  The component named "Box1:1" had its ModelState set to one named "iLogic", while the component named "Box1:2" had its ModelState set to one named "iLogic2".  Then when I opened the actual Part document, I noticed that it is currently set to the ModelState named "iLogic2", so it was the same as the second occurrence in the assembly.  I assume this is what allowed the rule to be found by that line of code in the main assembly, so it could be ran.  I don't know if this is a bug, or if it was designed to act this way on purpose, but it sure doesn't sound very user friendly to me right now.