iLogic vs. Macro Development

[emailY6U9U]

Looking for some guidance from more experienced folks: I have some tasks I want to automate, and am trying to figure out if it can be done in iLogic, or if it would be preferable to use VBA.

I went to use the VBA Editor to get started and all the warnings went off to use iLogic, so if that's the way everything is headed, I'll put the work in to develop it there.

The task: In a given assembly, I want to run a macro (how I've always done things like this in other programs) and have a series of drawings created automatically. One drawing for each thickness and material of Sheetmetal part containing just the flat patterns. (I.e. 12ga Mild Steel, 12ga Stainless, 3/16 Stainless, et.al.) I need to add a note within the outline of each part that pulls from both the part properties (for Part Number, etc.) and from the assembly (for total quantity.)

The drawings can be borderless, and will be automatically populated by the flat patterns of all sheetmetal parts of the same thickness and material type. All drawing views will be scaled 1:1. Notes will go on the zero layer and bend/hidden lines need to be removed.

A nice tool to build into this would be to run through and verify/create a flat pattern for all Sheetmetal details first, along with all of the other necessary programming checks to make this macro work.

I have a fair amount of experience programming in a couple of different languages, but not any VB or C# (at least recently.)

Pretty sure I've got the framework laid out well enough to start and I'm positive it can be done via VBA, just trying to learn if it makes sense to pick up iLogic from scratch to try to do this.

And if there's already a tool out there that someone has developed for this, I would be very grateful to have it as a starting point for what I'm doing.

Thanks all!

[R.Mabery]

I myself would do this in iLogic.  I only jump into VBA these days to look at the object model or some quick debug.  What you are asking for can be done in iLogic.

iLogic would make it easier to deploy such automation to other users.

You could also develop an add-in if you're comfortable with vb.net or C#.

[WCrihfield]

I agree with @R.Mabery.  I wasn't a career software programmer and didn't have a degree in programming (other than CNC machine programming), but now have years of experience writing a lot of both iLogic rules and VBA macros (not so much in Add-ins, due to corporate restrictions).  Although the VBA editor has a far more developed and useful user interface, and a nice built-in Object Browser that the iLogic rule editor dialog doesn't have, I still very much prefer creating my solutions using iLogic.  Inventor's iLogic is an Inventor Add-in that uses VB.NET as its basis, and has provided a TON of Inventor specific Interfaces, Types, and objects with lots of very useful methods, properties, and events to use to help us automate stuff in Inventor.  To me, using VBA is just a little older and clunkier feeling and the code is less condensed, often requiring more code to do the same thing.

One thing I do continue to use VBA macros for though is to be able to put buttons into my ribbons, so I can execute code with a single click.  I would gladly give up the VBA aspect of that equation though if Inventor would allow/expose a way to place buttons for iLogic rules directly in the ribbons (instead of 'macro' buttons) without having to have a macro run my rule, to set it up that way.

That's just my opinion though.

[pball]

Just to throw a different opinion in the mix. I've always taken the approach of having any code that is manually ran being a VBA macro, with a button on the ribbon bar. Then anything that I want automatically run on parts be an iLogic script. I have since transitioned from VBA macros to a VB.net addin but my thought process remains the same.

An example of each would by my addin has a script to print all drawings related to the open assembly, while an iLogic script in every part is setting a custom material iProperty on save among other things.

[A.Acheson]

I started 2 years ago as a complete rookie in coding so not any advance user for sure. Mainly to extract BOM to excel, then import iproperties to parts.
After a year of dabbling as inventor is not our main software  I dived into full ilogic template drawing automation, sheetmetal automation, PDF printing, view placement from assembly to drawing. I tried going the VBA route but found the learning curve too steep other than running complete codes. Modifying them proved too difficult and I found  switching between the environment etc was a little slow as was setting up buttons to run macros, not to mention figuring out what you named the module and or macro. 

So I started going down the ilogic route, setting up rules in forms as buttons. I liked the simplicity of its functionality of the rules being in notepad 🗒 and could be easily structured in the rule editor in folders and knowing any user could learn how to change a form or make a form  without much training. 
All of the information was gathered through this forum and other websites and by and large the content was ilogic/Vb.net related. Any codes that were VBA based were easily converted to ilogic. Debugging is a little crude with a message box but it does get you to really examine the way you write. 

Later on as I discovered the API help I started to noticing all the sample codes were VBA. But I still converted them all for ilogic environment. 

Now I am somewhat comfortable in modifying VBA but without a lot more training I wouldn’t be comfortable in writing there full time. It would most likely prove difficult to have other user use the VBA environment. VBA is still a good language to know especially if you utilize excel a lot but after learning how to launch excel from vb.net this isn’t a barrier. 

I would suggest try both and see what feels right, ideally learn both simultaneously and have the  best of both worlds. Look at the API help and know it’s there as it is needed when you get more specialized in the options you need.