I logic object reference error when moving, renaming, or editing forums themselves.

[J_Pfeifer_]

Good afternoon,

Been awhile since I've last posted, took a nice drafting hiatus, and now back to creating better versions of our templates. In creating this template, I had inventor itself (or what I assume to be inventor) kick out a debugging message to my screen.

When the error would appear from moving or renaming the rules themselves within the browser, there is a good change that Inventor itself will crash. It hangs super hard, and sometimes won't even display the error message. It also seems to effect how long it takes to edit a rule. That is, it takes longer to display the programming interface. This was what first happened, however making it crash from a rule movement is quite inconsistent. 

When the error appears while editing the form itself. Such as changing text box names for parameters to be changed. It would always display the error. Any changes after that error has been displayed, will not be saved to the form upon closing. I just close and reopen the form to make sure I don't lose work. 

See some of the attached pictures for visual of my descriptions. 

My general questions would be, has anyone experienced anything similar when you start getting a bunch of rules in a single document? Should I be using another method of storing these rules (External)? Could it be something inside my own programs creating this problem? Is there a known limit to the number or rules you can create within a single document? so, on. 

thank you, 

Jesse. 

@MjDeck

@WCrihfield 

[WCrihfield]

Well, I have seen 'similar' error before, but very, very rarely, and I can't remember what I did just before they happened anymore.  I have no idea about what caused it or how to fix it.

I also do not know if there is a limit to how many 'internal' iLogic rules you can have in one Inventor document, but if you have to question it, then you likely have more than you really need.  To each their own and all, but I try to keep pretty much all of my rules 'external' and all of my iLogic Forms 'global', with a few exceptions here and there.  I do have a ton of external ones, but they do not cause as much 'mischief' as internal ones can.

The primary difference in 'functionality' has to do with what are called 'iLogic parameters', which are those blue (by default), unquoted, parameter names, that get recognized as representing a parameter's value by the iLogic rule editor's 'Intellisense' system.  When those are present in your rule(s), then that rule will usually (can be turned off) automatically get triggered to run whenever the value of any of the ones in that rule changes.  If a single document has a bunch of them, and several (or all) fo them have those special parameters in them, then whenever you change the value of some of those parameters, there will likely be a whole lot of rules getting triggered to run, and a lot of processing going on.  The order the rules are in the document sort-of partially determine the order they will run in, if multiple are triggered at the same time.  That can also make for a lot of things for the iLogic system to manage (monitor) all the time.  Do you also utilize the iLogic 'Event Triggers' dialog settings?  If so, something in there may be a contributing factor to the issue(s), but not sure.  None of it should be causing that type of error though.

We can do all sorts of things from within iLogic rules, because we can use vb.net coding language from within them, so the possibilities / opportunities for something somewhere to be causing a pretty big problem are very relevant, but can't be predicted or diagnosed remotely by someone like me.  Likely something that the folks at Autodesk Tech Support may need to get involved with.

[J_Pfeifer_]

Yeah I've submitted a ticket and they recommended I make this post to the community with Mike tagged into it (Autodesk also have the direct part file). I specifically have stayed away from any of the event driven stuff within ilogic due to its straight through scripting nature. The programs in the browser I posted with (Auto) are issued based on ilogic parameters changing. Typically one or two that needs to make a general change to the model. Such as the insulation trigger. This searches and changes the suppression state of the main model, and any of the fittings / items attached to the model. That is, It searches through the extrusion collection to find specific named features, suppressing them in order to create a cut into this insulation that turns on and off with the main model. All of this is built on how I created and name the items within these collections (as there created by the main creation programs). Creates a list, iterates that list checking for changed values or items that need to be run. 

My hope was to auto generate a form based on this logic. Creating a "revision" form that populates all the fittings on the tank with parameters for the users automatically or at the creation. However, this is where I learned that ilogic itself is an Add-in. So the API itself has no access to this kind of function to make an Ilogic form populate. My plan was to allow users to make modification to standard input fittings through the form without any modeling or sketch changing. This is where you see the "LAUNCHED" rules. These are being launched by another rule that orders them to run based on pre populated revision form. The rule launches the other rules when pressed, checks for all the possible changes and issues them if and when those changes were found. I figured keeping these items ordered would be best in that way. All this to say that the (auto) are very simple flips or changes while the (Launched) needs to gather more information to compare or run through a case statement to change many of the variables. 

In the form limitation I learned that I could theoretically create a launched forum within ilogic that populates these upon a single button press. However all of these single button presses are starting to stack. Creating an order of operations, that would interfere with my ability to modify/simply these processes. Basically It looks like in order to keep going with all that I want to do. A dedicated add in would be the best option. As once setup I can use my already created Ilogic rules and otherwise in its own interface and more outside of iLogic. 

I spent an hour last night watching Mikes video from 2018 of setting up an Add-in to get the idea. Learned about the EXE stuff that can be accomplished, and so on. The only problem is, the 2025 .net update has made some of the references for doing this mixed / out of date. I don't know of a guide to setup an addin outside of old videos or Jelte de Jong's write up on the addin creation post 2025. In this I have a question, is the EXE stuff still accomplishable within 2025? Its still using the same COM's communication so I assume so. 

[MjDeck · Accepted solution]

Hi @J_Pfeifer_  - using an add-in or external EXE will definitely give you more flexibility than doing everything in iLogic. Comparing an add-in to an EXE, you can do more with an add-in. However it does take a bit of work to add buttons to the ribbon.
For an EXE, if you only need it to work in Inventor 2025 (and not earlier versions) that makes it simpler.
In Inventor 2025, there is a change in the code you need to connect from an EXE to the Inventor process and the COM API.

[MercuryOptimizationSolutions]

@J_Pfeifer_ , I've been rewriting the the Inventor AddIn template and I'm getting ready to release it, if you wanted to give it a try, you can download it from my website here: https://www.mercuryopt.com/downloads and go for the VB.NET Winforms setup. I'm still working on the training videos today but the intent is help iLogic developers make an easy transition.

Also, I rewrote the template so it automatically adds a button to the ribbon (addressing @MjDeck 's note above, this used to be the hardest part) and it has an Image Converting/Resizing module using your own button icon is wayyyy easier. If you give it a try, please let me know how it goes (here or email andrew@mercuryopt.com)

[J_Pfeifer_]

In digging over the weekend and getting a change to get my hands dirty on the environment. It seems that developing an ADD-in for our tools will give us quite a head start on the long term goals of the system while also giving me the functionality I seek. It seems that Autodesk has given the community a plethora of resources inside the SDK for viewing or interacting with. Using these I was able to create / modify a template for our in house use. 

@MercuryOptimizationSolutions What a nice looking site. I will have to take a deeper look into the templates and resources that you have posted and provided. Thank you.