VBA going away.

[shastu]

With the Conversations of VBA going away, I am curious as to what all I-Logic can do.  For example, I have multiple VBA codes that connect to other sources such as a database on another server, extracts information from the database, and then does something with that information.  So in order to do that, in my VBA code I have a connection string such as "strConn = strConn & "server=BCO-sql2\SL;INITIAL CATALOG=BCO_App;".  I don't know if there is any way to do that with I-Logic or not and if not, what is a way to accomplish the same thing?  I don't know anything about I-logic but have looked in the Inventor Help and don't see any answers.  Also, is there anything that is going to "replace" VBA within Inventor as a coding source, or is I-Logic the only way going forward to do any type of coding?

[shastu]

Looks like I posted a bit too early.  I found the documentation that says that you can "Connect to external database applications such as Microsoft Access or SQL servers." by using Integrated VB.Net in the I-Logic rules.  If anyone has examples for me of how to do that, it would be great, but I at least know it is possible now.

[pball]

I have not connected to databases like that before. But like you found it should be easily possible. Generally you can copy VBA code over to iLogic, with some updates to the formatting, both languages are based around visual basic

Another option available is to make an Addin. If you don't need iLogic triggers and you want buttons in the ribbon bar to run scripts, converting your code to an Addin might be the way to go. I personally have any scripts that would be manually run as an Addin and anything that runs automatically to edit Iproperties mostly as external iLogic scripts.

[shastu]

Thanks for your quick response. The one thing I was most concerned about is that all of my VBA code exists outside of any specific part, assembly, or drawing and is only executed when they push on the button created to run the macro from the ribbon bar. At first look I thought that I-Logic rules had to be created inside of a template, and then can be used on anything that is created from that template. The problem with that is that we have over 600,000 existing files that can be copied from that were not created from the template with the I-Logic rules in them and therefore will not be a good solution for us. Now I am looking into what it takes to create external I-Logic rule to see if maybe some of my simpler VBA codes can just be done that way.  Most likely, I will have to use Add-Ins for the more complicated macros.

[JelteDeJong]

iLogic gives you access to the full .NET Framework, which offers a lot of power—but that power can quickly lead to complex, hard-to-manage rules. Tasks like file operations or database connections often make iLogic code long and messy, and debugging becomes difficult when everything lives inside a single rule.

To keep your automation clean and maintainable, it’s better to move complex or reusable logic into a separate DLL (a compiled .NET class library). You can develop and test this DLL in Visual Studio, then call its functions from your iLogic rule. This keeps your rule short, focused, and easy to understand.

Using a DLL also enables you to build more advanced user interfaces than iLogic forms allow. With Visual Studio, you have full control over layout, behavior, and data handling—ideal for guiding users or presenting complex data clearly.

Another major advantage is reusability. The same DLL can be used across multiple parts, assemblies, or projects. When something changes, you only need to update the DLL once, and every rule using it benefits immediately.

External DLLs called from iLogic are excellent for organizing complex logic. However, in some cases, creating a full Inventor Add-In is the better long-term approach.

When to Use an Add-In

Custom UI Integration
Add-ins can add new ribbon tabs, buttons, and menus that feel like a native part of Inventor, giving users a seamless and professional experience.

Event Handling
Add-ins can listen for and respond to global events—such as opening, saving, or modifying documents—providing far more control than iLogic, which only runs when triggered manually.

Background Execution
Unlike DLLs called by iLogic (which run only when a rule executes), add-ins remain active as long as Inventor is open. This allows background monitoring, automated enforcement of standards, or other real-time tasks without user input.

More info here:

https://github.com/hjalte79/InventorAutomationWiki/blob/master/DllForIlogic.md 

http://hjalte.nl/tutorials/80-creating-an-addin-inventor-2025-and-later 

[hollypapp65]

VBA going?  Again?  For real this time?

Anyway, iLogic can use pure VB/API code which will be easier to move to API with Visual Studio.

iLogic code don't need to be in each file.  It can be code user run when needed or trigger by some event.  More advance event will require API.

[shastu]

Thanks,  I appreciate your thorough post.

[WCrihfield]

Hi @shastu.  I just wanted to add that iLogic offers other options besides having to resort to add-ins or DLL files for reusable, complex codes.  About 99% of my iLogic rules all exist as external files.  Not only can we create as many 'external' iLogic rules as we want, but we can also 'call' external iLogic rules to run from within other external iLogic rules.  These external rules are essentially just simple text files with one of 3 possible file extensions (".txt", ".vb", or ".iLogicVb").  We can also use some external rules the same way we would call Sub or Function type routine to run, and can 'send' data to the other rule, and 'receive' data back from the other rule, if set-up that way.  We can also designate certain external iLogic rules to be 'Straight VB Code' (the name of an Option within our iLogic rules).  The external rules with that option turned on can be used similarly to a DLL, and can contain custom Modules, Classes, and such, but without any need for Visual Studio.  I used to use VBA for a lot years ago, but the more I learned about the newer iLogic resources available to us, and about vb.net Framework coding, the more I started switching everything over to using iLogic.  I can still monitor custom events using external iLogic rules too, not just the few that are listed in the iLogic 'Event Triggers' dialog.  It is likely just a bit more difficult to manage those types of events using external iLogic rules, instead of using Inventor add-ins.  Since where have worked for well over a decade does not allow anyone to have administrative privileges to their own work computers, I have had to be a bit more innovate with iLogic's capabilities than some.  I have also reached out and controlled multiple other external applications through my iLogic rules, such as Excel, Outlook, MS Word, Notepad, and so on.  I haven't had much dealings with MS Access myself for a long time, but I know that we used to be able to interact with it through our iLogic rules, and likely still can.  I have even created, launched, interacted with, and reacted to the events in custom Windows Forms directly within a few of my external iLogic rules, without using Visual Studio.  But of course that was pretty complicated, and I wouldn't really recommend if you have better options available.

I am not saying that there is anything wrong with using external DLL's and/or add-ins, in fact they may be a better option, if you have administrative rights and are familiar with using Visual Studio.  I'm just pointing out that they are not the only options for achieving such functionalities, speaking from personal experience.  Through Inventor's iLogic resources, we are able to do so much more than most folks could imagine was possible.