iLogic vs. VBA – Similarities/Differences and Advantages/Disadvantages

[Anonymous]

Hi,

I have started learning and using iLogic to run a rule for a part file, and recently I found the VBA Editor in Inventor. What are the similarities and differences between iLogic and VBA? What are advantages and disadvantages of each? What are your experiences with iLogic and VBA? I'm trying to determine which one I want to use and why.

Thanks.

[Sergio.D.Suárez]

Hi, They are similar languages. Ilogic is more summarized, more compact. It has a series of useful shortcuts on the left. You can start doing logical actions without much programming knowledge. VBA is more reliable in most cases than ilogic. There are possible cases where ilogic can give some error that does not happen with VBA because it is more explicit. VBA is much more strict, the variables must be defined very well. In ilogic many times it is not necessary to define all the variables. VBA is more laborious to program, you have to place the "set" calls, etc. In VBA in turn I notice more complete in ways and other things. Ilogic is based on VB.net language from what I understand. Ilogic is very good to start and deepen later. It is simple to do quick tests.

However, most things that are achieved in VBA can be replicated in ilogic

It is the first thing that comes to mind now. regards

[pball]

I use iLogic for it's ability to be event driven, which allows files to auto update. I use VBA for manual operations where the user wants to do a task, such as exporting or printing. That is the main distinction I personally see between them.

As far as the differences go, the biggest is VBA being based off visual basic and iLogic being based off VB.net. It is easy to convert VBA to iLogic with some minor changes but iLogic to VBA can be harder if the iLogic exclusive commands are used. VBA used to have the better code editor but if you 2020 the iLogic code editor has been updated with autocomplete and other nice features to make coding easier. VBA still seems to have better debugging though.

I do not feel picking one over the other is required depending on your needs. If you must pick one for time constraints of not learning both, Ilogic might be the easier choice. But if you can spend the extra bit of time to learn the differences that will allow you to pick the proper tool for the job you are trying to do. For example making iProperties that auto update is easier in iLogic, while creating dialogs and code to manage multiple open documents at once can be easier in VBA.

[Anonymous]

Thank you both for your input! I appreciate it.

[JamieVJohnson2]

I'd like to chime in here.  So far everybody is spot on.  I would like to add this:

iLogic being a vb.Net compiling editor can run the SAME CODE as Visual Studio in a VB.Net project.  (don't try to get it to run a c#.Net page of code, it won't).

For me, this means I can create code in Visual Studio, test it, perfect it, probe things and all the power of MS VS 2019, then copy the code to iLogic and pretty much run it AS IS.  That is a one way street, because the iLogic short-cut code does not freely work in the VS editor that uses only the reference to Autodesk.Inventor.Interop (Active X library installed with Inventor, and version independent!)

Inventor iLogic shortcuts are things like

• "ThisApplication"
• "ActiveDocument"
• "ThisDrawing"
• "iProperty"
• "Parameter" 

These are easy ways to get to the chase of

• "Dim invApp as Autodesk.Inventor.Application = Marshal.GetActiveObject("Inventor.Application")", or
• "invApp.ActiveDocument", or
• "invDoc.PropertySets("UserDefinedPropertySet","NextAssembly").value".

The idea here is iLogic gives you shortcuts that the formal API requires you to perform properly.

VBA vs VB.Net:

VBA is MS VB version 6 or earlier

VB.Net is MS VB version 7 or later

There was a definite switch between syntax when they rewrote the language to run in the .Net Common Runtime Language (CLR) processor.  VBA requires "Set" statements and can not combine "Dim object as type" with "= class instance" (like the assignment of invApp above).  VBA editor INSIDE of Inventor CAN take advantage of some of the iLogic style shortcuts, BUT THEY ARE VBA SHORTCUTS (so they may not work exactly the same, but iLogic shortcuts were designed to imitate the existing VBA shortcuts when first created so they should be the same).  Both languages use the Autodesk.Inventor.Interop(Active X library) so they have the same 'object tree' access to Inventor under the hood.  Designing windows/forms is different for each platform/editor combo you choose.

iLogic Editor:

The iLogic editor does not do "object orientation" easily.  It does perform Public Class definitions, but you generally want to separate all that code into separate pages.  For iLogic's editor to organize a full project of classes and methods can get a bit messy, but it does offer access to outside files (code defined in an external document and then referenced). iLogic does not 'pre-compile' its code, so anybody can read/modify the code (this could be good or bad).  I have successfully gotten iLogic to run VB.Net code that references the windows multi-threaded processing environment (System.Threading) as well as the same code in Visual Studio (since Inventor 2019), so you can write some powerfully fast code with iLogic/VB.Net that way (whole new can of worms!).

User controls (Forms/Windows/Palettes):

1. Inventor.Interop allows certain control over the Inventor GUI to allow you to create native Inventor Commands, with their custom button icons and keyboard shortcuts.  This can be done in all 3 editors (VBA, iLogic, Visual Studio).  Custom controls can also be added to an Inventor Palette as a host of user window set of controls.  This combines Inventor familiarity with custom tool designs.
2. VBA uses Windows Forms and has a powerful but older set of controls to build your own windows/wizards, command buttons and the like.
3.  VB.Net uses Windows Presentation Foundation OR Windows Forms depending on the project type you setup.  WPF is the most modern controls editor, allowing for great style-ability based on XAML language (similar to HTML but not).
4. iLogic editor has its own forms creator for custom controls.  It simplifies much of the boiler code to create direct access to parameters and iProperties.  However that simplification totally limits its abilities.

There is a breakdown for you that points out a bit more physical differences.  I hope it was helpful.

[Anonymous]

I don't know how to run a ilogic rule with a keyboard hotkey without using VBA. I only use VBA only for making macros which I can assign keyboard hotkeys. These are simple macros that in time become complicated. I use these macros frequently when designing.

The advantages i see with ilogic is easier coding testing and form making if you are a beginner. Also it easier to move these rules from computer to computer if u are not using Vault. 

[JamieVJohnson2]

You would use a different method, by defining a command in the command editor of the inventor application.  Then it can have a button, and keyboard shortcut, and appear in the marking menu.

[freesbee]

---

@Anonymous wrote:

I don't know how to run a ilogic rule with a keyboard hotkey without using VBA (...)

---

...if I remember it right they are planning to offer the possibility to assign iLogic rules to ribbon buttons (I am not 100% sure of this). Maybe once that will be out, also keyboard shortcuts will have the possibility to be assigned...

[JelteDeJong]

I created an addin that allows you to create buttons for iLogic rule. With that addon, you don't need to wait for further releases of Inventor. More info about the "Button Constructor" on my site.

More on the topic of the original question. I think VBa is obsolete. More info in this blog post: "Is VBA in Inventor obsolete?".

[yan.gauthier]

Here's my grain of salt:

VBA is quick to start with, test, debug. Since you have everything you need from the IDE (no need to install anything else). In VBA, you can debug and just explore you objects if you are looking for a specific variable or something (e.g.: if your macro is not working, by looking to the document object tree in the debugger, you might find out that its property RequiresUpdate is set to true and is the reason things aren't working.)

In Ilogic, you won't have that sort of developping/debugging function. Its only advantage is the access to event driven rules

If you ever want to do prior test in Visual Studio Environnent, the debugger only have clear access to object to specifically called. some other object will be identified simply as object. Debugging makes it a little more tedious. But, if you ever get to that point, then you are half way through building an addin.

I strongly recommend switching to C# if you go the .NET addin route. Why ? cause Microsoft are no longer developping VB.NET and nowadays, new .NET project, modules are developped in C#. You will get much more support that way.

Of course the addin path is the one with the hardest learning curve, but it will give you access to every events defined in the api documentation, not just the few ones Ilogic triggers provide.

To me, QOL/manual commands are done with VBA macro (also some tests) and anything that handle sensitive information or is event driven is from my Addin. Addin also gives you the opportunity to develop custom UI. in my case, I have several WPF UI window that runs on separate threads so they don't block Inventor like the vba forms do.

I just believe Ilogic is one tool too many. if the rule is on file then, its hard to update. if it's global, then you miss the point of Ilogic. Since the only other advantage I see is its portability. 

[kkongphobss]

I want to learn VBA to create custom add ins for my design team. Please can you share the guidelines with me.