Inventor API: Custom add-in #3 – Working with the API, implementing the functionality

Hello there!
It’s time for the last part of our small tutorial on writing Inventor add-ins. Today we’ll write the actual implementation of the functionality described in previous post and explain some other small details. So, let’s get to work!

INVENTOR HANDLER

Our main functionality will be performed by a single class – InventorHandler (which will also be abstracted by IInventorHandler interface). It’s going to have only one public method AutoBreak() which will be responsible for applying the break to correct view. Let’s start with constructing it.

Private fields

It consist of three private fields: invInstance which stores reference to current instance of Inventor apllication, settings which stores reference to settings model and comparer which stores reference to IComparer implementation for sorting drawing views descending, area-wise.

This implementation is actually an internal class within our InventorHandler class. We won’t need that anywhere else.
Next, we have static list which contains orientation types which can work with our auto-break. This means that all views which are different orientation will not be take into consideration when executing auto break.

That list contain only perpendicular projections (back, left, right etc.) and the one called kArbitraryViewOrientation. This is the type of all views generated from a base view. This mean that although isometric views are not present this our collection the add-in will break that kind of view if it is created from an existing view.
The last thing is a predicate that is used for removing all views which are orientated differently than types allowed in the collection that we have just explained.

Constructor

The constructor for our InventorHandler class is very simple. It sets invInstance and settings to those given as arguments and instantiates new DrawingViewSizeComparerHelper class.

AutoBreak();

Now, let’s go through our only public method in the class:

It takes current active document in running Inventor application and sets a reference to in in a local variable drawing as a type DrawingDocument. Although property ActiveDocument of invInstance is of Document type (which is more general than DrawingDocument) it is safe to set is as DrawingDocument as our button to execute will be visible only in Drawing ribbon, therefore we’re sure that the active document IS DrawingDocument.
Next, we set another local variable which is of type DrawingView and assign result of getBiggest method executed with argument of drawing.ActiveSheet. This gets currently activated sheet in active document. If it’s null (meaning no drawing views are in the sheet) or it is too small to be broken the add-in will display a message and terminate execution of AutoBreak method. Otherwise, it continues.
Now, it checks if there already is a break applied to the view. If it is, again, it displays appropriate message and terminates.
Next step is to determine start and end points for the break. They are of type Point2d and they are set as local variables inside the method’s body. To give them appropriate values one of two methods is invoked: horizontalPoints or verticalPoints. These methods return boolean whether it is possible to break, and outs break points.
The last step is to apply the break:

It is done by executing Add method of BreakOperations collection in a view. It takes several arguments, as follows:

  • BreakOrientationTypeEnum – break orientation;
  • Point2D – start point;
  • Point2D – end point;
  • BreakStyleEnum – style of break, rectangular or structural;
  • integer – display level, in our case we pass default value of 5;
  • double – gap between left and right part of the view;
  • int – number of symbols, works only for rectangular view;
  • bool – propagate to parent view, defines if the break will be visible in parent view, in our case we pass default value true.

And that’s it. That’s the workflow. Now, as you probably noticed the method described above uses few private methods. To fully comprehend how the add-in works it is necessary to describe them as well.

DrawingView getBiggest(Sheet _sheet)

This method finds the biggest view in the given sheet. All views which are not orientated correctly (remember the list of ViewOrientationTypeEnum?) will be excluded from the selection.

bool isHorizontal(DrawingView _view)

Simply checks if a view is wider than higher and returns true if does.

bool canBeBroken(DrawingView _view, bool _isHorizontal)

This one checks if a view is sufficiently wide for horizontal break, or sufficiently high for vertical break. Minimum height/width is 5 cm plus gap. Remember that the API operates on centimetres expresses in variables of type double.

bool horizontalPoints/verticalPoints(DrawingView _view, int _percentage, out Point2d _start, out Point2d _end)

These two counterparting methods calculate start and end points based on given view and percentage of the view that needs to be removed. Methods return boolean whether a break can be applied and outs the points.

Converters

As some values from settings model are of simple types while methods exposed by the API require some arguments of different enum types there are two converters in the InventorHandler class: one is to convert boolean to BreakOrientationEnum

and the second one is to convert integer to BreakStyleEnum:

And that’s it if it comes to our InventorHandler class. However, to make the add-in actually work there are some changes needed in StandardAddInServer class.

CHANGES IN MAIN ADD-IN CLASS

First of all, we need an instance of InventorHandler. We’ll create a private field for that and initialise it in the constructor:

The last step is to modify action that is fired when the ‘Apply’ button is clicked:

And that’s it. The add-in is now functional. See the demo below:



FINAL REMARKS

There are two things I want to mention at this point. First, is about embedding the stdole assembly. When it’s added to the project and the project is built you will get a warning message:

Although, it does not affect the build you can get rid of these messages by setting Embed Interop Types property of stdole reference to false:

The other things is a word of explanation about NameValueMap interface. It used (amongst other uses) in the API to pass parameters in the events (as in our case events fired by clicking buttons). It works similarly to dictionaries, it stores pairs of name (which are strings) and values (which are of type object). I will not describe it in details (if you need that, simply go to its metadata in Visual Studio), but now you know the main thing – it is name/value pair to pass event parameters.

 

CONCLUSION

A vast portion of things can be manually done in Inventor can be automatised. However, the freedom in modelling that software gives you makes it really difficult to develop universal add-ins that will work always, no matter what you’re modelling. But all of translation, conversion, export things can be easily worked with. I know that there are some add-in that allow to generate models of sprockets, pulleys etc. and that works perfectly.
The hard thing when developing add-in is debugging. Possibilities here are limited because every time you want to debug you need to build your project and run the application, and you won’t get any error messages – either the application will crash, the add-in will be disabled or it won’t be executed.

To make things clear – I have worked with that software as a professional for more that 5 years and I am a big, big fan. I have experience with others systems, but this one seems to be most user-friendly, most of the features works as you would expect and has that professional-feel. But, it’s not a review, so I’ll stop here.
Thanks for your time, I hope that it is in any way useful for you. Good luck!
Michal

GitHub repo: https://github.com/mickaj/AutoBreaker-Inventor

Inventor API – Custom add-in Part #1
Inventor API – Custom add-in Part #2

Inventor API: Custom add-in #2 – Functionality and UI

Hello!
Writing our add-in for Inventor continues! Agenda for today’s post is simple: first I will write a word or two about what is the functionality of the add-in, then I will present the UI and what settings it provides, finally I will present the code.

FUNCTIONALITY

So, what will the add-in do? It allows user to place initial break to the biggest view in the drawing. It is rarely required in real world but the purpose of this demonstration is not to write something widely useful but to present how to write basic add-in for Inventor. Nevertheless, I wouldn’t be surprised if someone finds actual use for it. Feel free to do that 🙂
Inventor allows to set some parameters of the break. First and the most important is orientation. In our case that will be determined not by the user but automatically depending on proportions of the view. The rest will be allowed for customisation. As this is not an Inventor tutorial I am not going to describe in details how to manually add the break and what exactly can be customised. For such pieces of information you can easily find something on YouTube (for example this[1]).

UI PRESENTATION

As our add-in is very simple its UI is equally simple. Combo box for break style, slider for number of symbols (for structural style), text box gap which value will be converted to double and is expressed in centimetres, and slider ratio of how much of the view will be removed (minimum is 10%, maximum is 90%, however if the view is to small the break will not be applied). This small dialog is built in WPF and follows the MVVM pattern.

CODE

As this add-in will use WPF user interface I want it to follow the MVVM pattern, therefore we need model and view-model.

Model
So, let’s start with the model as this one is the simplest:

Style parameter is represented by an integer property backed by a field. The property setter allows only two values: 0 and 1 – that’s how two possible options are represented. Other possibility could be for instance a boolean, however integer is simpler to use with combo box. Similar situation with Symbols where setter allows only 1, 2, or 3 to be assigned; and with Range which can vary from 10 to 90. Gap is auto-property of type double. Class constructor sets initial values which are hard-coded. Natural extension would be to save those values somewhere so they are saved between sessions, however it’n not the point at the minute. The model class SettingsModel is additionally abstracted by ISettingsModel interface.

View-model
The view-model is slightly more complicated, but still quite simple.

First and foremost – it implements INotifyPropertyChanged interface. Fields and properties reflect the model, there are two things that require explanation. Range field/property backing field is of type double which is consistent with its counterpart in the model, while property is of type int which is consistent with slider’s value property. Gap field/property is of type string which will be bound to a textbox. The view-model also contains reference to model which is set via default constructor, constructor also assigns values from the model to respective fields in view-model. There is only one method which is used to save values from view-model to model; and there is only one command which invokes SaveToModel() method and closes settings dialog.

As mentioned SaveCommand is used to save values from view-model to model. It can be executed only when Gap value in view-model can be parsed to doubleExecute(object parameter) method casts parameter to type Window and invokes its Close() method to close the window. This require passing open instance of settings window to command parameter, which will be explained below.

View
Now, the view. There is one trick with WPF windows in Inventor add-in. If you try to add a WPF component to the project you will see that only user control is available, but the problem is that we need a window. A way to tackle that (source[2]) is to add what we can – a user control, and then change it to window. You need to do that in XAML code of the window and in the C# code behind. In XAML change root node to <Window>…</Window>, in C# code modify your class so it inherits from Window not from UserControl. And that’s it.

The only intresting thing in the XAML code above is how current instance of window is passed as command parameter:

The command parameter value is set to binding with RelativeSource set again to RelativeSource in FindAncestor mode with type of Window. This way  the current instance of window will be passed as command parameter which in turn is closed by the command.
Other than that, there are not exceptional things in the XAML, simply built UI with typical binding to view-model.
What you probably noticed, is that data-context is not set, and instance of view-model is not created in XAML, which requires the view-model to have parameter-less constructor, therefore some changes to add-inn StandardAddInServer main class are required.
Another thing worth mentioning is that closing (without saving settings to model) by clicking ‘Cancel’ button is achieved simply by an event assigned to that button, not by a command. This way to do that is much, much simpler than a command and because of the fact that it doesn’t interact with neither model nor view-model it doesn’t break the MVVM pattern.

Updates in StandardAddInServer
First thing that we need to do is to instantiate a model. The main class will be equipped in private field of type ISettingsModel […]

[…] which will be initialised in the class’ constructor.

The last thing we need to do is open the settings window when appropriate button is clicked. To do that we need a method that will be fired when the button is clicked.

The method above creates new settings window, sets it data-context to new instance of SettingsViewModel with current model as constructor’s parameter and finally shows the window as dialog.

And that’s it. Next (and the last) step will be to make ‘Apply!’ button to work. So, don’t forget to check my blog a little bit later.
Thanks, Michal!

GitHub repo: https://github.com/mickaj/AutoBreaker-Inventor

Sources:
[1] – https://www.youtube.com/watch?v=BzUAb9Qvu98
[2] – http://adndevblog.typepad.com/manufacturing/2015/11/wpf-window-inside-an-inventor-add-in.html

Inventor API – Custom add-in Part #1
Inventor API – Custom add-in Part #3

Inventor API: Custom add-in #1 – Introduction & modifying the ribbon

Hi!
Long time no see I might say… But there is a reason for that. As I mentioned in my previous post I turned my focus onto add-ins for Inventor and I have spent some time on that. Now, the plan is for short series of three post about writing add-in for Inventor. It will consist of three episodes: one – introduction and modifying the ribbon; two – description what the add-in we’re going to write in this series will do and its user interface in WPF; three – everything that resided under the hood and presentation how it works with Inventor.

TOOLS

In terms of tools there is nothing special needed. Obviously, Inventor needs to be installed and it’s SDK that comes along with the package. I do not own a licence for Inventor, but Autodesk allows for free 30-day trial to test their packages. The trial is for full package with no feature-limitations, however it is not allowed to use it for “commercial or for-profit purposes” [see here][1]. Writing these posts does not and will not violate either of those conditions, nonetheless if you are willing to write an add-in that will be used commercially you cannot do that with the trial. That having said we can move forward.
Once you have it installed it is necessary to install the SDK. It is an .MSI package you need to extract. It can be found in your Public Documents folder, then /Autodesk/Inventor2018/SDK. The package we’re interested in is developertools.msi. It will deliver some samples and – most important – project templates for Visual Studio. Unfortunately, the templates are for VS2015 so if you’re using VS2017 you will need to install older version as the templates will be installed only if Visual Studio is installed. If you still prefer to use VS2017 you can create project ins VS2015 and then open it newer IDE. I have not encountered any issues.

To sum things up, you will need:

  • Microsoft Visual Studio 2015 and optionally  Visual Studio 2017
  • Autodesk Inventor package which you can download with trial licence if you are not using it for commercial or profit purposes
  • Autodesk Inventor SDK developer tools installed that comes together with the software package

KNOWLEDGE BASE

Before I move on to the project I’d like to recommend two sources of knowledge about Inventor API. I already mentioned them in my previous post but to keep things organised I will do it again here.

  • Object Model Diagram – it is a PDF file that comes with the SDK developer tools and can be found in PublicDocuments/Autodesk/Inventor/SDK/DeveloperTools/Docs
  • this[2] repository on Git Hub. It contains thematically organised lessons on Inventor API with examples in C#

STARTING THE PROJECT

As mentioned before the templates are available for VS2015, so creating the project must be done in VS2015. All code written this series will be available on Git Hub. You will find a link at the end of this post.
Another thing that is important is to use correct version of .NET framework. I will be using Inventor2018 and it uses version 4.5. As I am aware most recent editions of Inventor uses 4.5 but if you want to be absolutely sure you can check that. To do that you need to go to your Inventor installation folder, then /Bin and open Inventor.exe.config file  in any text editor, then find <startup> tag section:

In the section above, the sku attribute defines version of the framework and in this case it is 4.5.
Having the project created you can save it, close and re-open in VS2017 if you prefer. Otherwise, you can continue in VS2015.
The last step would be to edit some values in AssemblyInfo.cs.

The project template is set up in a way that one the project is built all necessary files will be copied to appropriate location so the add-in will be visible in Inventor.
Having this done we almost can move on to modifying the application’s ribbon.

PROJECT REFERENCES

But before we start playing around with Inventor we need to add some references to the project. Right after project creation we only have references to autodesk.inventor.interop and System. We need bit more:

  • PresentationFramework – our UI will be build using WPF. You could use WinForms and I think that’s the preferred library, however I like WPF more. And that is the only reason for my decision.
  • System.Xaml – needed for WPF
  • stdole – that provides IPictureDisp interface that is going to be used for converting embedded icons to those usable with Inventor ribbons
  • System.Drawing – that provides Image abstract class and Icon class, needed for the same reason as above
  • System.Windows.Forms – that may seem suprising as I’ve already writtten that we’re going to use WPF. The reason behind the need of that reference is that AxHost base class to build our converter from Image objects to IPictureDisp usable with Inventor ribbons.

MODIFYING THE RIBBON

The application has several different ribbons. Which is used depends on what type of document is active and what environment is being used. To divide this series into episodes which are more or less equal length-wise I will just say now that the add-in will operate in drawing environment and will have two buttons: one to setup its preferences and the other one to run actions to be performed by the add-in.

First I will prepare two icon for our buttons. I downloaded some free icons from here. (I am absolutely talent-less if it comes to drawing). We need two size of each icon: 128×128@32bit and 16×16@32bit and they must be set as embedded resource. They will be stored in img folder in our project. So, to summarise: 4 files = 2 different icons x 2 different sizes.
Unfortunately, those icons cannot be used as they are. First, they must be converted to be of type IPictureDisp. To achieve that I’m going to use this[3] implementation (as proposed by Andrew Whitechapel at MSDN) of such converter:

As you can see our AxHostConverter class is an internal sub-class within our project main class StandardAddInServer. It won’t be used anywhere else so this approach is absolutely safe.
A method that creates instances of button definition as icons takes argument of type object, therefore they will be declared in StandardAddInServer class body as objects:

They will be in fact of type IPictureDisp in stdole namespace, but because of the fact that Inventor namespace also contains IPictureDisp type and avoid that confusion I will keep them as of type object. The process of retrieval from embedded resources and proper conversion will be performed by a private method getIcons() inside StandardAddInServer class:

So, that was the most confusing part. Now, it’s time start messing with the API. Adding our buttons to the application’s UI we need to start with defining some members in the class’ body:

The above fields will be initialised in another private method modifyRibbon(). The separate method is not needed however I like to have it separated just for a bit of clarity.
addInGuid string is copied value of Guid attribute from class signature. It will be later used to simplify a bit invocations of methods defining new buttons.

First two steps are easy, we just need to get some objects from currently running instance of Inventor, and that’s it.
Next step is to create command category for our add-in. It is done as in the code above, where arguments are as follow: strings for display name and internal name, and guid. Internal name is built as follows: “Autodesk:CmdCategory:our_custom_name“. This will add our category of commands that will be visible in UI customisation dialog:

Next, we need to access intended ribbon and one of its tabs. The ribbon we’re interested in is Drawing ribbon, the tab is Place Views.

As you can see they are accessible by their unique names and you must know them. They all can be found in mentioned earlier Git Hub repository here[4].

Next step – defining buttons:

It is achieved with use of ControlDefinitions and its AddButtonDefinition method. It takes several arguments (in respective order):

  • display name (string)
  • internal name (string) following scheme “Autodesk:command_category_name:button_name”
  • CommandTypesEnum – type of command, for UI elements it should be kQueryOnlyCmdType
  • add-in guid
  • description (string)
  • tool-tip (string)
  • standard icon (of type object, but it needs to be IPictureDisp)
  • large icon (of type object, but it needs to be IPictureDisp)
  • ButtonDisplayEnum – a way a button is displayed, in our case it is kAlwaysDisplayText

Once the button is defined we need to add action that will be performed when the button is clicked.

It the example above customAction method must return void and take one argument of NameValueMap which is set of name and value pair. It will be explained in one of later posts. For the time being, this method will only display a message box to demonstrate the buttons actually work.

The last step of defining a button is to add it to command category:

Now, we need to add panel to Place Views tab.

It is acheived using Add method in RibbonPanels collection in one of the ribbon tabs. It accepts arguments as follow:

  • display name (string)
  • internal name (string): “Autodesk:command_category_name:button_name
  • add-in guid

Now, we need to add our buttons to the created panel:

In the example above AddButton takes three arguments:

  • button definition
  • boolean – use large icon
  • boolean – display text

So, that’s it. The ribbon is modified. After changes described above it looks like that:

Nothing more to add today. Check the links below and stay tuned for the next part!
Cheers, Michal

GitHub repo: https://github.com/mickaj/AutoBreaker-Inventor

Sources:
[1] – https://www.autodesk.com/licensing/trial-license
[2] – https://github.com/ADN-DevTech/Inventor-Training-Material
[3] – https://blogs.msdn.microsoft.com/andreww/2007/07/30/converting-between-ipicturedisp-and-system-drawing-image/
[4] – https://github.com/ADN-DevTech/Inventor-Training-Material/blob/master/Module%2009%20-%20User%20Interface/RibbonNames.txt

Inventor API – Custom add-in Part #2
Inventor API – Custom add-in Part #3