Question about Triggers
It is usually a good idea to design those types of codes to first check if the parameter's value or expression already matches what you want it to, before proceeding to set its value or expression to what you want it to be. This avoids making the document 'dirty', and may avoid some unnecessary triggering too. As you likely already know, when you include the unquoted name of a local parameter within an internal iLgoic rule, every time the value of any of those parameters changes, it will trigger the rule to run. And if there are multiple of those unquoted local parameter names present within the rule, then the rule may get triggered to run once for each of them that gets changed. I highly doubt that the system is smart enough to bundle several parameter value changes into a single event, just because of 'how' they got changed. You could try eliminating all of those unquoted local parameter names, and/or turn on the 'Don't Run Automatically' option, then either use a different means of running the rule, or create your own custom event handler code to control when the rule gets ran, but that seems like it could be too much effort if this is just a minor annoyance, and not actually causing any problems.
Wesley Crihfield
(Not an Autodesk Employee)
To answer the first question you asked in your original post, about why we would want this behavior, I can't speak for everyone but I do not necessarily want it to act that exact way. To make it only run the rule once, after multiple parameter values have changed, would require disabling the 'on parameter change' type triggering, and instead use something like, 'run once per document update event in which any parameter values were changed' to run the rule.
In essence, the rule does just run once per parameter change, but there were two parameter values changed, and both of those parameters were present in that one rule, as unquoted local parameter names, not just one, so it caused the rule to run twice (once for each parameter's value that got changed).
It is difficult to explain / describe why it had to be this way, without going the details of how all the different possibly related events work. The main event that is getting triggered here is the ModelingEvents.OnParameterChange. There is a separate event for when a parameter is created, but not separate events for the different types of parameters, or for what caused the change. All those other details, like determining what type of parameter it was, or figuring out what caused the change (name changed, value changed, units changed, etc), the have to be figured out by the event handler block of code that gets ran when the main, basic event happens. And since this event is raised each time a single parameter has changed, the block of code within that event handler does not know about any other parameter changes that may have happened around the same time, just the one it is dealing with at that moment. So that block of code can either react to that one specific event, or not react to that one specific event. If we were to create our own collection of event handlers, all within one Inventor ApplicationAddIn, with this exact scenario in mind, we may be able to discern if multiple parameter changes are happening to a single document, at around the same time, and formulate a plan for dealing with that scenarion differently. But if that were possible, determing what to do when the first of multiple parameter change events happens would be very difficult, because it does not know if more parameter changes will be happening after this one or not, so how should it decide if it should react to this event or not?
In the first couple sentences of my last responce, I was just referring to a common practice of checking if value is already what you want it to be, before attempting to set its value. For example:
If Param1 <> 3.25 Then Param1 = 3.25...or
If Parameter("Param1") <> 3.25 Then Parameter("Param1") = 3.25But I no longer thing that would make any difference in this matter. If a parameter's value is set to the same value it was already at by code, that does not trigger the rule to run, and does not dirty the document. If I manually open the parameters dialog, and type over that parameters value, setting it to the same value it already was, that does dirty the document, but still does not trigger the rule to run. But if the document gets dirtied, that will usually lead to an update being needed later, and a prompt to save before closing. Just minor details that may make processing take longer in a large assembly later.
Generally, if I have multiple unquoted local parameter names in my internal iLogic rule, and one or more of them is not triggering properly anymore, I need to click the 'Regenerate All Rules' button to fix it. I had to do that just recently. For instance, if you created the iLogic rule with that parameter name in it, before creating that parameter, then created that parameter, it remains unassociated, and the triggering does not immediately work, until you click that regenerate tool.
Wesley Crihfield
(Not an Autodesk Employee)
