I'm starting to develop some customization for Inventor, and I need to decide whether to use VBA, .net, addin, plugin, or what else.
According to this post .net is easier to use than VBA: http://forums.autodesk.com/t5/Autodesk-Inventor-Cu
I did a quick test and I found out that with VBA is much easier to use than .net: you can edit the source code while debugging, you don't need to compile and install anything, everything seems to work much smoother.
Am I missing something?
Do I risk to find out that VBA has problems later in the development?
Where can I find documentation with comparison between the different customization techniques?
For small hacks VBA is nice for productivity. For larger products VBA is a weak language, VBA is not meant for nice OO code.
One thing that is superior is Visual Studio as code editor.
The debugging experience is far better from VBA though, from Studio I only see COM object for most Inventor stuff while in VBA I can browse the hierarchies in a nice way. Maybe I am doing something wrong here?
My typical workflow is to write a small proof of concept in VBA and then rewrite it in .Net
Any comment about the interface/interaction?
Management of ribbon, panes, forms?
Management of graphic area actions like selection by pick, selection by windows, drag & drop, context menus?
I have experience with other systems, I'm just trying to figure out what is the best approach.
This post, at the end, says that I can't debug a .net application with a 64 bit computer:
Is that still true with Inventor 2012?
If that is the case I don't see how the productivity of a .net environment could be higher than a VBA environment.
I will stick with VBA... unless there are other limitations with VBA.
Yes, it is going to be a full work environment, and it will take me 3-4 months to build.
I will have:
- a set of tools to help me create sketches with images in the right position and with the right scale;
- a dialog with a tree view and a few buttons to navigate through my components and images;
- a set of tools to gather information and create reports for sales, estimating and engineering departments.
I am reading about the different customization techniques, and building my belief table (see below)
If the table is correct then the right solution could be to build a plugin, easy enough to debug, and when it's stable convert it into an addin, to improve the performance.
Do you think it's a good approach?
- easy to debug
- easy to install
- good performance
- not a good long term solution, because Microsoft already abandoned it
- not a good short term solution, because of poor object oriented management and poor interface
- easier to debug than addin
- more difficult to debug than VBA
- low performance (it's out of process, right?)
- best performance (it's in process, right?)
- half nightmare to install
- full nightmare to debug
I can't speak to that as I have not tried all of them. I just know what I've done with just the tools in Inventor.
I have assemblies that use similar parts. So at first I had the basic part shapes as clickable icons. One icon would create an excel file. So as I click the parts, it asks for the excel file and then I click on the one I just created. This tied all the parts together as I would just change values or have excel lookup values. So other than some code for the icons, most of the work was done in excel and was able to use regular excel functions.
There was another project where I have inventor draw up custom shipping containers made of planks of wood. The box dimensions always vary. So you enter the number in excel and it sorts the available board sizes and determines how many are needed to make the box. Inventor then draws the box with hinges. I just save the excel file, hit update in inventor, and the working drawing is ready and I hit print. No VBA for excel needed.
So now I am utilizing Ilogic to get away from interfacing myself with excel. I still use it through Ilogic but I can enter everything inside Inventor and instead of several basic part shapes, there are fewer parts but with selectable part shapes. Then the assembly can dictate certain dimensions and parts and also have part numbers of the off-the-shelf parts handy. This project isn't 100% complete but looks like it will be slick. I only knew some VBA before using Ilogic which I guess is based on VB.net. I haven't found any big road blocks despite being a hacker in the original sense of the term (hacking my way through it).
Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register
Start with some of our most frequented solutions to get help installing your software.