API pulling User Parameters within a sub component

[ndillner343SKL]

Within an upper level assembly I'm launching rules within sub components that contain model states. Within these sub components I'm taking the user parameters and setting them equal to the corresponding excel cell value. When doing this it will occasionally not run the rules within the sub components, it'll say the rule ran but it will have ran in maybe .1 seconds and not have changed any parameters. This issue is new with Model States. 

I'm wondering if it has to do with the "ThisDoc.Document" method of calling parameters? 

Upper level assembly launches rule.

iLogicVb.RunRule("PartNumber", "Master Rule")

Part of the Sub component rule that updates parameters. (Contains Model States)

[j.haggenjos]

If you remove the try/catch block, do you get an error?

[ndillner343SKL]

On some components, yes. Due to them having some parameters that are “stand alone” and don’t have a corresponding excel cell.

[j.haggenjos]

If at the start of the rule, you have a message box similar to this:

MsgBox(ThisDoc.Document.DisplayName)

Do you get the message box for the component where the rule has no effect?

Also, I'm not familiar with ModelState as we have not migrated yet to 2022. Are the component that don't get updated somehow suppressed in the main assembly? This may cause issues. You could work around it by activating the component, rule the rule and suppress it again.

[ndillner343SKL]

Appreciate the responses. I added the message box at different stages of the code and intentionally broke the model and found that it is properly identifying the component and model state even when the code has no effect. And yet when I open the model and run the code there it runs just fine. This leaves me to believe that it has to do with the model state somehow being out of date. Even though I've used all the code I can think of to keep it up to date. I'm stumped. Thanks for the help though. This was very helpful for me to ensure that the ThisDoc.Document is in fact working properly.

[WCrihfield · Accepted solution]

This is an interesting case, and sounds very similar to what we were dealing with in this other forum thread:

https://forums.autodesk.com/t5/inventor-ilogic-api-vba-forum/create-model-states-using-ilogic/td-p/1... 

It kind of seems like there might be a bit of a bug in the system related to running local rules when a ModelState other than "Master" is active.

I did a few fairly simple tests on this theory.  When I have a part document open/active, I can run this one local rule (within that part) while this part is in either the "Master" model state, or when it is in another model state.  (The rule just uses a MsgBox to show FullFileName of the part.)  So that isn't it.  Then I saved and closed this part (while it is still in the 'other' model state, and opened an assembly in which this part is represented in as multiple components, then used a simple local rule in that assembly to run the local rule in that component, it failed...the first couple times.  That specifically named component was still set to its Master model state, while the part document itself was currently set to its 'other' model state.  This caused the local rule in that 'component' to not be found, and therefore not to run.  However, after I manually changed the model state of that component from Master to the other model state, it must have changed something in Inventor or in the session memory, because after that action, my local rule in the assembly was now succeeding in running the local rule in that component.  This stayed true no matter which way I changed the model state of that component in the main assembly afterwards.  This behavior really sounds like a bug to me.  It seems like the model state of that component just needed to be messed with just that one time, before it would allow the rule in that component to be found, then it didn't matter what following changes were made, including setting it back to the way it originally was when the problem existed, but the problem no longer exists when set back that way.