Moving from internal to external rules

[luke.scottWYFAG]

Hi everyone,

I am in the process of making some of my internal rules external (with varying degrees of success).

I have been using the code that chandra.shekar.g posted in this topic "Deleting suppressed parts and patterns down multiple levels with ilogic - Autodesk Community - Inven...

Its brilliant and works just as I was after but things fall down when I make it an external rule.

I know there are some changes that are needed but have no idea what they are or where to start looking. Does anyone have any useful tips and pointers?

thanks for any help.

[CCarreiras]

Hi!

There are specific rules that can't be set as external rules due to the way that some operations need to work, and they only work if they are local in the file.

Maybe the rule you're using is one of these cases.

[luke.scottWYFAG]

Ah ok, I will run through and work out where the code falls down then hopefully that will give me a specific command that needs to be looked at. thanks. 

EDIT: Apparently going to make a cup of coffee, asking on the forums and turning it on and off again was enough on its own to make inventor decide that the bit of code would like to run. I have spent a bit of time this morning on other things within my top level assembly as well so maybe things got a little confused and a restart was all that was needed.

[WCrihfield]

Hi @luke.scottWYFAG.  One of the main things to look for in local/internal rules that will not translate/work in an external rule is when you are using the unquoted names of parameters within your local rule.  They turn blue, by default, when they are recognized as local parameters.  That relationship is lost when the rule is moved to an external rule, because there is no longer a 'local' document (the document that the rule was saved within).  One of the simplest ways to work around that scenario is to switch 'HEIGHT' to 'Parameter("HEIGHT")'.  Both of those will represent your parameter's Value in 'document units', which is nice and convenient.  Or you could go the API route, but that would include a lot more code.

API route:  PartDocument.ComponentDefinition.Parameters.Item("HEIGHT").Value

However, when going the API route, you have to deal with 'database units'.

[WCrihfield]

I forgot to mention another point about those local, unquoted, blue parameter names in local rules...

When you use them in a local rule, it causes the rule to be automatically ran (triggered) every time the value of one of them changes.  This functionality is sometimes highly desired, and other times unwanted, depending on your situation.  Anyways, when you move from using 'HEIGHT' to using 'Parameter("HEIGHT")', you will loose that functionality too.  So, if any of your automation plan is dependent on that triggering functionality, you may want to leave some of those rules as they are (local).  There are other ways to achieve, or maintain that triggering functionality, though.  One thing I often do is leave an extremely simple local iLogic rule in the document, which just contains some 'dummy' variables (not used for anything), which have their values set using those unquoted, blue, local parameter names.  Then, right after those dummy variables, I simply use a line of code to run the external rule that contains the real code. (for example:  iLogicVb.RunExternalRule("MyExternalRuleName"))  That way, I get the benefits of the triggering, and the benefits of using external iLogic rules.