Hi @GeertvanderHeide. While this behavior is somewhat common, there may be things you could do to help make it run more efficiently, so that it doesn't run certain rules so many times, if it may not be necessary. I do not know what is causing the "INFO|Body's uit zetten" data to be written to the iLogic Logger that many times, but I assume there is a loop within your iLogic rule that is writing that out every time it loops. If you are using the Event Triggers dialog, and either the "Any Model Parameter Change" event, or the "Any User Parameter Change" event, to automate the rule mentioned in that post, then you may be able to improve performance by utilizing a very simple internal/local iLogic rule's triggering behavior instead of using that Event Triggers dialog. As you know, when using either of those Event Triggers events, the rule will be ran every time any of that type of parameter is changed, which can cause a lot more triggering than may be necessary. To avoid that, yet still maintain the necessary amount of triggering behavior, you could create an internal/local iLogic rule (saved within that document) then use what I call a 'dummy variable' (a variable that is not used for anything) that is set to the value of a blue unquoted parameter name (blue by default, only within an internal rule), then another line of code that simply runs the appropriate external rule that you want to react to that parameter change event. That way, only when that one specific parameter's value changes, will this rule be triggered to run, then it will simply run your external rule. Then, if using this techique, remove that external rule from the Event Triggers dialog, under those 'Parameter Change' type events, and you may notice that the rule gets ran fewer times, which increases efficiency.
Below is a very simple example of an internal rule like this:
oTrigger = MyBlueParameterName
iLogicVb.RunExternalRule("MyExternalRuleName")
There are also some settings you could play around with that may also help improve efficiency, if valid for the situation. There are some lines of iLogic code that could be used to help control general iLogic behavioral settings, such as:
- enabling/disabling the ability of rules to react to (get triggered by) parameter change events
- enabling/disabling the ability of rules to react to (get triggered by) any Event Triggers settings
- Enter/check if within/Exit 'Delayed Rule Running Mode', which can be used to 'pause' all other rules from running due to parameter change events and other events, until you exit this mode. Then when you exis this mode, you can choose whether to then allow all those rules that were triggered to run, to now run, or simply resume normal behavior. Below are some of those lines of iLogic code:
iLogicVb.Automation.RulesEnables = 'Boolean
iLogicVb.Automation.RulesOnEventsEnabled = 'Boolean
iLogicVb.Automation.EnterDelayedRuleRunningMode
iLogicVb.Automation.InDelayedRuleRunningMode 'ReadOnly Boolean
iLogicVb.Automation.ExitDelayedRuleRunningMode(Boolean)
These settings that can be set by code will not override any settings you may have set in the user interface dialog (the Options area of the Event Triggers dialog, or the Security Options area {iLogic Security} of the iLogic Configuration settings dialog).
Edit: And there are also some settings you can access by code, for individual iLogic rules, that can also help control their ability to be 'triggered' (as well as some other settings), if you do not want to to effect 'all' rules. And you can also simply suppress other internal rules by code, then do some things, then un-suppress those rules again, to avoid them running a bunch of times while you are doing some other things. Just throwing some ideas out there.
Wesley Crihfield
(Not an Autodesk Employee)
