How do you structure lengthy iLogic projects?

[logan_armagost]

I'm struggling with how to structure a big iLogic project I'm working on. Generally when programming, I'll start by writing everything in one file and then as that file gets longer and longer, I'll start to break functions or subroutines into separate classes (often different files entirely) to keep things organized. So I'll have a class that handles all my excel related stuff and a class that handles processing of user input values, etc. Then my main script imports those classes to make use of their functions and class-level variables. 

I've just gotten to this point in my iLogic project. I'm over 1000 lines of code and it's getting a little cumbersome to navigate, so I'd like to break things apart into more palatable sections, not only for myself while working on it, but for others that might have to edit the script in the future. It's much better to have all your functions and procedures logically organized into a dozen descriptively-named files than one massive script with 100 short-hand-named functions. Unfortunately, I'm finding it pretty difficult to get iLogic to import classes the way I'm accustomed to doing. Usually a single line of code does the trick. ie. import Class1. Later on in the script: length = Class1.lengthInput. 

I'm trying to figure out the best way to handle this in iLogic with the whole "ThisRule" issue where as soon as you make a custom class, everything breaks and doesn't work anymore. There's AddReference, but that wants a dll. Not entirely sure how to make that. I thought AddVbRule would do the trick, but then the rule (class) I'm trying to import has to be "Straight VB" which would require me going through and rewriting everything I've already worked on in iLogic to make it VB. I guess in hindsight maybe I should've just done everything in VB to begin with to avoid the limitations of iLogic that I was unaware of at the time. There's the SharedVariables thing, which sounds great for variables, but I can't make use of functions from other rules, which is a lot of why I would want to import the class. I'm trying to not have to copy and paste the same functions into several different files (generally considered bad practice). I feel like this workflow is pretty standard for programming, but iLogic is really fighting me here and seems to want me to just slam everything into one big file with no class-level distinctions.

What is generally the recommended way to structure a rather lengthy iLogic script in the event that you don't want to be contained to one super long file that's a nightmare to sift through? Is there no way around me rewriting everything to be straight VB if I want things to be clean and organized? 

[g.georgiades]

When using the iLogic editor, you can expand or collapse functions on the right side (at least in inventor 2025). You can also use #Region xxx / #End Region to make a large section of code collapseable. That is the extent of quality of life features available to the iLogic editor.

When I do need to use multiple files - it is usually because I have generic functions that can be used in multiple places.

I personally am not a fan of AddVBFile as I run into issues were ilogic does not recompile the file if I edit it then I have to restart inventor to clear the internal memory. Other users have stated they do not see this issue, so it may something with how namespaces or static variables are being used. I am not sure.

I really only use iLogic's built in method to enter and exit other rules. This has the benefit of no needing to use the Straight VB option and you can pass any custom parameters you want. It is not quite as convenient as having a proper class, but it works pretty well.

Dim imap As NameValueMap = ThisApplication.TransientObjects.CreateNameValueMap() ' pass file name to other rule
imap.Add("fPath", filename & ".idw") 'dont show input prompt
imap.Add("filter", "idw") 'dont show input prompt
imap.Add("fullfPath", CStr(Path1))
iLogicVb.RunExternalRule("Vault - Find and Open FIle.iLogicVb", imap)
Dim result As Boolean = imap.Value("result") 'did we succeed?

There is a bit more details in this help doc

https://help.autodesk.com/view/INVNTOR/2025/ENU/?guid=GUID-32B66838-22E4-4A0A-B5BB-862350C76B36

Personally, I use visual studio to write all my ilogic rules. It is quite weird in terms of workflow and a few users on the forums have developed their own flows, but the editor is much nicer. It has a document outline which makes getting around long files easier, I can jump to variable definitions or search where methods and variables are used, and I can debug rules. Contrary to popular belief on this forum, there is no need to compile any rules into dlls which are much harder to work with.

[WCrihfield]

Hi @logan_armagost.  Great topic.  I'm sure you will hear lots of interesting opinions and useful suggestions / insight on a topic like this.  I would like to be able to go the DLL route, but that just seems to not be possible for me at the moment, due to certain restrictions where I work.  So, I have opted for one of the next best options...the 'AddVbFile' route, with several external iLogic rules where their 'Straight VB Code' option is turned on.  However, there is still a way to utilize some / most of the uniquely iLogic objects/methods from within those types of external resources, depending on how it is set up.  One way to enable that is to ''pass' one or more of the iLogic 'Rule Objects' to the external resource, one way or another.  Two of the best iLogic objects to pass to it are the ILowLevelSupport Interface, which is represented by the 'iLogicVb' variable in our iLogic rules.  The other is the StandardObjectFactory Class, represented by its name 'StandardObjectFactory' which seems to have already been instantiated for us in our iLogic rules.  And even if you passed the 'iLogicVb' object to your external resource, I still recommend using its ILowLevelSupport.CreateObjectProvider(document) Method, which results in an IStandardObjectProvider Interface, the same as using the StandardObjectFactory.Create(document) Method.    With that, you can create most of the other common iLogic 'Rule Objects' from within your external resource, and set them to the same 'variables', like the terms used within our regular iLogic rules.

The formatting differences can be difficult to get used to, if you don't have a long history of using strict vb.net though.  Sometimes when you go use the external resource from another regular rule, it will throw errors at first, until you actually create an instance of the Class using its New method, and supply any required inputs.  Then the errors will go away.

[WCrihfield]

I also use a relatively common tactic of keeping most of my iLogic rules external, and most my iLogic Forms 'global', so that they can be reused, or called to run from other rules or events.  And a common practice is to set the rule up so that it can 'receive' certain data from another rule, if called to run that way, or obtain that data another way if not ran that way.  Like @g.georgiades, I too like and commonly use the tactic of 'sending' data to other external iLogic rules, and 'receiving' data from other rules.  It is just another way to use an entire external iLogic rule as if it were a custom Sub routine, or Function, with 'input parameters' or be able to 'return' a value from it as a Function would.  This may, or may not be, the most efficient way of doing things, but it certainly helps reduce redundant code being copied in multiple places, where it can get outdated, and allows for updates/changes to be done in one place, rather than multiple places.

I do still use internal iLogic rules in a few places, but when I do, I keep them extremely basic and short, where they are primarily there to take advantage of specific parameter value changes triggering them to run.  But then the rule will simply run an external rule to react to the parameter value change event, and may even 'send' local data to that external rule.  That way, the local rules are 'disposable', do not need to be edited, because they are not doing the 'main' tasks.

And to respond to one of the details mentioned by @g.georgiades earlier, which I may partially agree with, about needing to sometimes restart Inventor to clear Inventor's memory.  This is likely because of 'event handlers' being created/started/managed by iLogic rules.  Although this is possible, and I have done it quite a bit, and continue to, it seems like it is not as easy to 'manage' as when using something like an Inventor add-in.  When we create and start an event handler with an iLogic rule, a copy of that rule will remain 'active' in Inventor's session memory until that same rule either eliminates it, it naturally expires due to its 'source' being disposed of, or will remain active in Inventor's memory until you quit Inventor.  Because that copy of the code stays in Inventor's session memory, changing the original rule's code will not change the version of code already being held in its memory, which remains 'active'.  So, if you just created and started an event handler, then realized that you need to change something about it.  You will either need to do the action that your code is expecting to stop that event handler, or you will need to quit Inventor to get rid of it, so that you can fix its source code.  And it seems like it may be possible to 'stack' multiple event handlers for the same 'event' on top of each other, which will reduce Inventor's performance.  To avoid this, those types of iLogic rules which create them must be pretty carefully, and thoughtfully written, with an 'exit plan' in place for eliminating that event handler when something else happens.  Some events are easier to manage than others, but in general, it can be complicated to manage properly and efficiently.  There is a method for clearing Inventor's 'clipboard', and one for clearing the iLogic 'clipboard', but I don't think they would work on event handlers.  Not talking about the iLogic Event Triggers dialog settings here, but true vb.net event handlers.

[ryan.rittenhouse]

I have similar methods for large iLogic projects.

I break up rules by their discrete functions - mostly for troubleshooting and code management purposes . A lot of what we do has assemblies and sub-assemblies that need to run iLogic. Anything that needs to be is run at the top level, but we push as much as possible down to the sub-assemblies and they run their own iLogic. Like Wes, we do as much as possible in external rules, usually with a single local rule (we use "Update") to kick off all the needed external rules. I'll break rules down by broad function. For Example, in an ETO stair landing assembly, I'd have a rule to sanity check the inputs, one to turn features on/off on the landing itself and push parameters to it, one to manage added glass/hardware to it, and another to updated needed Views or metadata. By default, most of our assemblies have an Update rule that is just full of external rule calls (often with checks to make sure the called rules finished without error), a sanity check rule, And a part update rule - we do almost all iLogic from the assemblies and try to avoid running it in the parts unless there is a compelling reason to do so.

Anything that is used in multiple places is put in a global file and used through AddVbFile. We make very heavy use of the Object Provider to call iLogic rules, access the iLogic API wrappers, and make use of the logger in the pure VB sections. We also use global functions as wrappers for iLogic rules to make it simpler to pass data back and forth with the rules. We still send RuleArguments with direct rule calls a lot, but for a few instances, especially when you only need a single value back, we'll make a wrapper function and lean on that.

I do my pure VB dev (and some of my external rule development) in VS Code and most of my direct external rule development in Inventor since it will validate my code every time I save and is better w/ Intellisense most of the time. Copilot in VS Code is great for writing boiler plate functions and doing the docs/instellisense for your subs and functions, but not really any good when it comes to writing iLogic stuff.

Hope this helps.

[C_Haines_ENG]

Subs, Functions, Classes, and Formatting!

Subs and Functions are a given, if you are doing the same thing multiple times it helps to create a callable sub or function to do the task instead of taking up more space.

Classes are a big one for me, it sucks to remember 10,000 variable names, so you can put them inside classes if they get called on frequently. They also keep things very organized, and have ALOT of useful features. Classes contributed to a significant increase to the complexity of my programs.

You can use '[ and '] to create a collapsible region. You can format it like so:

'[ THIS SECTION DOES COOL STUFF

    Sub DoingCoolStuff
        Does cool stuff
    End Sub

    Function DoingCoolerStuff
        Does Cooler stuff
    End Function

'] THIS SECTION IS DONE ITS COOL STUFF