Problems with parts not updating when "ThisApplication.ActiveDocument.Update" is used.

[SMillsYS3X2]

I'm trying to get an assembly to run from a top level user form. Very little iLogic used, and mainly driven with linked parameters and formula. My problem, I've been trying to use the command "ThisApplication.ActiveDocument.Update" as a button/run rule/command on the form, but it is not always effective. There are some parts that just don't resize/rebuild, even after the rule/button has been used repeatedly. It will work if I open the problematic part and manually rebuild with it open.

Is there a way to run through all the parts and force a rebuild at each part? Or failing that, is there a way to use iLogic to open and part and rebuild a specific part there? I can identify the few problem parts and use such a rule.

[A.Acheson]

Hi @SMillsYS3X2 

Can you indicate what you think the rebuild all is attempting to do when it works? Is there a part with a lighting bolt active when you open it? Automating will just try to do what is required manually so knowing the exact steps you need to do will be a helpful start in helping. Are there any errors occurring with constraints or sketches etc? Rebuild all isn't always necessary when the geometry is updating cleanly. 

[SMillsYS3X2]

No, no lightning bolt icon to show a rebuild is needed. The form button/rule can used repeatedly until all update indicators are gone. And sometimes it does take 2 or 3 rebuilds. But two different parts of this assembly just don't change with the changed form inputs until I open and rebuild them directly. One is a singular unique part that only has a few parameters being driven. (see first picture) The other is one part that us used twice in a sub assembly of the top level assembly. It is a Sheetmetal part with 3 model states, and only driven by 2 linked parameters. (see second picture)

[SMillsYS3X2]

A co-worker thinks that these two parts are just not being notified that their driving variables have actually changed, so the rebuilds skip them? Trying to use iLogic to push a variable to these parts directly, and so trigger the resizing.

[A.Acheson]

Can you verify exactly how the update is triggered. Are you using rebuild all, entering the parameters window, changing a parameter? I have noticed in the past that editing a sketch and exiting could be enough to trigger an update. I assume actually updating the part isn't enough when the document is opened visible?

Another way to check is to loop through the documents, find the part, find the parameter that is meant to be changing and run it through a message box, record the value, make a change in your driving file and see if the message box comes up with an old or new parameter value. Then you can start checking what parameters update at what point in the code. Just some thoughts for diagnosing.

[SMillsYS3X2]

The update is triggered first by a person updating a form from the top level assembly, which change parameters at that top level, which then has iLogic that copies those parameters to a control part that then has parameters linked to these and many other parts in the assembly. It is also triggered by a button on the same form that runs an iLogic rule that is just that one line. Well, started with that one line. I've been trying to modify it to force a change on these two problem parts.

It is frustrating because the 10+ other different parts and sub-assemblies are updating fine, and these two parts WERE fine until I did some revisions to how an different sub-assembly is controlled. 

[SMillsYS3X2]

Unwanted solution - Instead of driving the parts with linked parameters, I am switching at least one variable to be driven like an adaptative model. Seem to work. Don't like being forced to use this instead of a more formula or iLogic solution. Still testing to be sure it's stable.