Announcements
Attention for Customers without Multi-Factor Authentication or Single Sign-On - OTP Verification rolls out April 2025. Read all about it here.
WCrihfield
in reply to: llorden4

Hi @llorden4.  This is a good, and interesting topic.  For me, which one I would prefer to use usually depends on where and how I am planning on using them.  Obviously we can only use the line 1 example within an 'internal' iLogic rule, while the example on line 3 can be used in either an internal or external iLogic rule.  So, the Line 3 example is more flexible, if your internal rule may later need to be converted into an external rule.  They do both act differently though, and knowing how they act differently is key to their proper use, and knowing when to use them for best results.

 

The primary 2 advantages to using the example on line 1, is:  1)  The compactness of the code (just the name of the parameter (if the parameter's name is short) 2)  The automatic triggering of the rule to run when the value of that one specific parameter changes.

The first advantage mentioned, only an advantage if the name of the parameter is not very long.  I guess you could count the parameter name turning blue, in recognition an advantage, but I never really saw it that way myself.  The second advantage is only an advantage if you 'really' wanted the rule to be triggered every time 'every' parameter name being used within that rule changes.  We do have a setting to turn that triggering off, but for the whole rule, not just for specific parameter names.  

 

One thing that both have in common is the ability to directly Get/Set the value in 'document units', instead of in 'database units'.  However, this so called advantage can also be confusing, because we are talking about 'document units' not actually the parameter's own units.  For example, if your document units were Inches, but this parameter was set to some other units, such as feet, yards, miles, millimeters, etcetera, then units conversions would still be needed, because the parameter's true value, in its own units is neither document units nor database units.  At this point we practically have to create our own custom Functions to get/set a parameter's value in the parameter's own units, when they are different than both the document units and database units.

 

One think to always keep in mind when working with the Line 1 example codes, is that you will need to use the:

RuleParametersOutput

This is apparently the name of a Sub routine that has been defined within the 'ThisRule' Partial Class that gets created automatically for us in the background within our iLogic rules.  This is apparently needed at intervals within any longer codes using those blue, unquoted parameter names, in order to push any changed values to the model, because otherwise this action will not happen until after the rule has finished.  In some longer rule cases, this 'update' needs to happen before the end of the rule, because other calculations are being done with those 'changes' in mind, but those changes have not taken place yet, unless you have used that Sub to push those changes to the model.

 

On the other hand, when using the Line 3 example codes, we have the IParamDynamic object (represented by the 'Parameter' iLogic Rule Object), and all its Properties, such as UpdateAfterChange.  We can set this to True near the beginning of our rule, then when any iLogic snippet code starting with 'Parameter' is used to change a parameter value anywhere in that rule, after that point, it will cause the model to update, which is nice (if the update does not take a long time to process).

Wesley Crihfield

EESignature

(Not an Autodesk Employee)