Part document update explanation?

[J_Pfeifer_]

I think I've gotten the Inventor software crash I've been fighting for the last couple of days solved. However in doing so a bunch of trial an error ensued. 

I'll attempt to keep this short, when accessing already created parameters tied to features I was having all of inventor itself crash out. Looking at the crash reports it seem to have been calling to things multiple times and failed to interact with the features(circular patterns, extrudes, etc). 

Something kept telling me that updates were processing before I'd like them to, or they would process due to a change without my notice. In talking to a coworker who works on other programs and tools (Outside CAD). He suggested I turn off the automatic updates. 

Once I focused into this direction I came across many different interactions or locations this can be changed. 

We have a checkbox in the FX parameters "immediate update", we have Automation.SilentOperation / Automation.EnterDelayedRuleRunningMode, Also IlogicVB.UpdatewhenDone, then you have the two versions of doc.update / doc.update2, and two versions of doc.rebuild / doc.rebuild2, then you have things like screen updating that have nothing to do with the document. 

Once I had clicked the checkbox in the FX parameters, and applied the IlogicVB.updatewhendone to the rules crashing the software. It seemingly had solved all my issues. Could someone explain how they interact with each other? Or an explanation of how inventor processes data and issues changes would help deepen my understanding so that I could better plan for these things in the future?

[WCrihfield]

Hi @J_Pfeifer_.  That's a complicated situation, with a lot of settings and methods mentioned, so I likely won't have the time to explain every detail, but I can get things started.  I certainly can not tell you exactly what setting or method caused your problem, but I might be able to help explain what they are for, or what they do...at least as much as I know about them.  Some of those settings may be in two different places to, and have different 'scopes' (areas of effect).

The 'SilentOperation' setting is for suppressing unnecessary pop-up dialogs while your code is running.  That setting is in 2 places...at the application level, and at the iLogic add-in level.  The one at 'iLogicVb.Automation.SilentOperation' is at the iLogic add-in level, the other one is right under the Inventor.Application object in the Inventor API.  Using the iLogic one is relatively safe, but when using the Application level one, you should use a 'Try...Catch...Finally...End Try' statement, so that no matter what happens (such as an error which stops the rule), it will go to the Catch or Finally side, where you will turn that setting back off.  Same for the Application.ScreenUpdating property...be careful, and plan for errors.  Setting the 'iLogicVb.UpdateWhenDone' property to True, is just a rule scoped preparatory statement that will cause 'the document' that the rule is focused on to update when the rule has finished running.  That line can be placed at the start of a rule, instead of at the end of it, and is very safe to use.  The Document.Update, Document.Update2, Document.Rebuild, and Document.Rebuild2 methods should only run once, at the moment they are called to run.  In most cases the regular Update method will suffice.  The '2' version just offers us a way to 'ignore errors/warnings' that may pop-up while it is updating.  The 'EnterDelayedRuleRunningMode' is unique to iLogic, and is a way to 'pause' any rules that would normally be triggered to run by the 'Fire Dependent Rules Immediately' setting, or rules that may be 'triggered' to run by parameter values changing due to using the 'blue', unquoted parameter names within internal iLogic rules, and will cause those 'triggered' rules to wait until the deliberately ran rules get done, then they can run.  It is a management tool.  It is usually not unsafe to use, but can be pretty important to make sure it is set right, for your 'design intents or plans' to work out right.

[J_Pfeifer_]

Just getting back to this, sorry. 

Would it be correct to say that the silent operation and delayed run mode are both toggle boxes within each rule? we're not required to program this in, its just something we can do. The options in the rule should take care of these correct? 

Is it also correct to say that if the program starts with the updatewhendone = true. nothing will be updated until the program has been fully finished, including sketches, features, so on?

So in practice, I should start with updatewhendone = true. Then from there update or solve sketches throughout the program directly controlling the update item and time?

I found that some of the issues I was running into was not so much an updating problem within the program. It was seemingly because a couple of the sketches I had created were based on reference geometry that was broken when certain toggles were on or off. Making me think that because these were messed up, the programs went to update the document. Attempting to force update a broken sketch, crashing Inventor itself. I only found this after hitting rebuild in certain configurations. Once I changed the modeling to no longer rely on these references, it seemed to have stabilized the runtime. 

[WCrihfield]

Within our iLogic rule editor dialog, on the Options tab at the top, are 5 checkbox type settings on the left, then on the right is a couple controls for changing text color and font.  Those 5 checkbox settings are scoped to just that one rule...not all rules, and yes, they are manually controlled.  We do have access to those same settings for 'other' rules, but usually not to those settings of that rule itself, from within that rule, by code.

• iLogic Rule level 'Silent Operation (iLogicRule.SilentOperation Property)
• iLogic add-in level 'Silent Operation' (accessed through 'iLogicVb.Automation.SilentOperation' code phrase ;  IiLogicAutomation.SilentOperation Property)
• Application level 'Silent Operation' (Application.SilentOperation)

The 'delayed rule running mode' settings are not limited to specific (or specified) iLogic rules though, they is more like an iLogic add-in level settings.  They can be reached through the 'iLogicVb.Automation' code phrase, and are as follows:

• IiLogicAutomation.EnterDelayedRuleRunningMode Method 
• IiLogicAutomation.InDelayedRuleRunningMode Property 
• IiLogicAutomation.ExitDelayedRuleRunningMode Method 

When entering that mode, all rules that are 'triggered' to run by the values of parameters changing and similar 'events' will be 'delayed', allowing the already running iLogic rules to finish first, and allowing the already scheduled to run rules to finish running.  Then, when you exit the delayed rule running mode, all those rules which were 'triggered' to run by events during that delayed mode, will be allowed to proceed and run.  That setting is controlled by code.

However, one manual 'rule level' setting named 'Fire Dependent Rules Immediately' (iLogicRule.FireDependentImmediately Property) can be used very similarly, because when it is set to False (off), then other rules that are triggered to run by parameter value change events while this rule is running, will wait until this rule finishes running before they run.

Then the other manual rule level setting named 'Don't Run Automatically', which coincides with the iLogicRule.AutomaticOnParamChange Property, can be used to simply turn on or off this rule's behavior of automatically running whenever the value of one of its parameters changes.

In general, these 'parameter value changing events' that they refer to is only relevant for 'internal' iLogic rules which contain those blue, unquoted parameter names, because their presence enables that type of triggering.  Because of this, it does not effect external iLogic rules, because they can not utilize those blue, unquoted parameter names that way.

The 'UpdateWhenDone' setting (ILowLevelSupport.UpdateWhenDone Property) is also a 'rule level' setting.  Its documentation does not say that it will 'prevent' any other types of updates until the end of the rule...only that, when set to True, it will update the document when the rule finishes.

I hope these direct Links to online help documentation, and explanations help clear up some of the confusion.  Glad to hear that you figured out some of the issues which may have contributed to the crashes.