Mod the Machine

Create an iPart

To make a part into an iPart, you use the CreateFactory method of the PartComponentDefinition. The iPartFactory returned by the call to CreateFactory does have a TableRows collection but it does not have an Add method and the way to add the rows that you need for your iPart, may not be obvious.

My colleague Philippe Leefsma has this example that shows what needs to be done. It uses the Excel Spreadsheet returned from the ExcelWorkSheet property of the iPartFactory to create the table used to define the functionality of the iPart. In this visual studio project you will find the CreateiPart Sub Procedure and a couple of other procedures. One adds a new row to the iPart and the other prints the contents of the table to the immediate window.

Public Sub CreateiPart()

 

        Dim oPartDoc As PartDocument

        oPartDoc = _InvApplication.Documents.Add _

          (DocumentTypeEnum.kPartDocumentObject, _

     _InvApplication.FileManager.GetTemplateFile _

         (DocumentTypeEnum.kPartDocumentObject), _

                                             True)

 

        oPartDoc.SaveAs _

            ("c:\Temp\iPart_By_API.ipt", False)

 

        Dim oTG As TransientGeometry

        oTG = _InvApplication.TransientGeometry

 

        Dim oCompDef As PartComponentDefinition

        oCompDef = oPartDoc.ComponentDefinition

 

        Dim oPoints(3) As Point2d

 

        oPoints(0) = oTG.CreatePoint2d(0, 0)

        oPoints(1) = oTG.CreatePoint2d(5, 0)

        oPoints(2) = oTG.CreatePoint2d(5, 5)

        oPoints(3) = oTG.CreatePoint2d(0, 5)

 

        Dim oSketch As PlanarSketch

        oSketch = oCompDef.Sketches.Add _

                    (oCompDef.WorkPlanes(1))

 

        Dim oLines(3) As SketchLine

 

        oLines(0) = _

            oSketch.SketchLines.AddByTwoPoints _

                        (oPoints(0), oPoints(1))

        oLines(1) = _

            oSketch.SketchLines.AddByTwoPoints _

          (oLines(0).EndSketchPoint, oPoints(2))

        oLines(2) = _

            oSketch.SketchLines.AddByTwoPoints _

           (oLines(1).EndSketchPoint, oPoints(3))

        oLines(3) = _

            oSketch.SketchLines.AddByTwoPoints _

                    (oLines(2).EndSketchPoint, _

                     oLines(0).StartSketchPoint)

 

        Dim oProfile As Profile

        oProfile = oSketch.Profiles.AddForSolid

 

        Dim oExtrude As ExtrudeFeature

        oExtrude = oCompDef.Features. _

           ExtrudeFeatures.AddByDistanceExtent _

            (oProfile, 15, _

            PartFeatureExtentDirectionEnum. _

                     kPositiveExtentDirection, _

        PartFeatureOperationEnum. _

                           kNewBodyOperation, 0)

 

        oExtrude.FeatureDimensions(1). _

                            Parameter.Name = "Length"

        oExtrude.FeatureDimensions(2). _

                        Parameter.Name = "TaperAngle"

 

        Dim oFactory As iPartFactory

        oFactory = oCompDef.CreateFactory

 

        Dim oWS As  _

            Microsoft.Office.Interop.Excel.Worksheet

        oWS = oFactory.ExcelWorkSheet

 

        oWS.Cells(1, 1) = _

 "Member<defaultRow>1</defaultRow><filename></filename>"

        oWS.Cells(1, 2) = "Part Number [Project]"

        oWS.Cells(1, 3) = "Length<free>150 mm</free>"

        oWS.Cells(1, 4) = "TaperAngle"

 

        oWS.Cells(2, 1) = "iPart_By_API-01"

        oWS.Cells(2, 2) = "iPart_By_API-01"

        oWS.Cells(2, 3) = "150 mm"

        oWS.Cells(2, 4) = "0 deg"

 

        oWS.Cells(3, 1) = "iPart_By_API-02"

        oWS.Cells(3, 2) = "iPart_By_API-02"

        oWS.Cells(3, 3) = "100 mm"

        oWS.Cells(3, 4) = "5 deg"

 

        oWS.Cells(4, 1) = "iPart_By_API-03"

        oWS.Cells(4, 2) = "iPart_By_API-03"

        oWS.Cells(4, 3) = "50 mm"

        oWS.Cells(4, 4) = "10 deg"

 

        Dim oWB As  _

          Microsoft.Office.Interop.Excel.Workbook

        oWB = oWS.Parent

 

        oWB.Save()

        oWB.Close()

 

        oPartDoc.Update()

        oPartDoc.Save()

 

    End Sub

Wayne Brill

Create a Mini Toolbar

New user-interface elements such as the mini-toolbar were introduced in the 2012 release. The mini-toolbar could be a welcome addition to your application’s user interface and making one is fairly easy. In this example a Visual Basic forms application is used. (Similar steps could be taken to create the toolbar in your Add-In)

Here are the steps to create this example.

1. Using Visual Studio in a Windows Forms application, add a class. (Name it something like clsMiniToolbar). Also add a button to the form.
 

2. In the click event for the button have it create a New clsMiniToolBar.

Private Sub Button1_Click _

        (ByVal sender As System.Object, _

         ByVal e As System.EventArgs) _

                        Handles Button1.Click

        Dim oMiniToolbar As clsMiniToolbar = _

                            New clsMiniToolbar

    End Sub

3. At the top of the code window for clsMiniToolbar add the following Imports:

Imports Inventor

Imports System.Runtime.InteropServices

4. Add the following declarations to the class. These variables will be instantiated in the constructor for the class (Sub New) that will be added following this step.

Public Class clsMiniToolbar

 

    Dim invApp As Inventor.Application

    Dim started As Boolean

 

    Private WithEvents m_miniToolbar _

                         As MiniToolbar

    Private WithEvents m_button1 As  _

                        MiniToolbarButton

    Private WithEvents m_button2 As  _

                        MiniToolbarButton

    Private WithEvents m_button3 As  _

                        MiniToolbarButton

    Private WithEvents m_combo As  _

                        MiniToolbarComboBox

    Private WithEvents m_dropDown As  _

                        MiniToolbarDropdown

5. Add the Constructor for clsMiniToolbar. When this class is created, the invApp variable is instantiated with the call to GetActiveObject. If this is successful createMiniToolbar is called as long as there is a document open.

    Public Sub New()

        Try

            invApp = Marshal.GetActiveObject _

                       ("Inventor.Application")

 

        Catch ex As Exception

            MsgBox _

       ("Need to have a session of Inventor running")

            Return

        End Try

 

        If invApp.Documents.Count > 0 Then

            createMiniToolbar()

        Else

            MsgBox("Need to have a document open")

        End If

    End Sub

6. Add the createMiniToolbar Sub Procedure. The CreateMiniToolbar method of the CommandManager is used to instantiate the m_miniToolbar variable. You then use the MiniToolbarControls of the MiniToolbar to add the buttons, ComboBox and Dropdown.

 Public Sub createMiniToolbar()

 

        m_miniToolbar = _

         invApp.CommandManager.CreateMiniToolbar

 

        Dim controls As MiniToolbarControls

        controls = m_miniToolbar.Controls

 

        m_button1 = controls.AddButton _

        ("MyButton1", "Button 1", "This is button 1")

        m_button2 = controls.AddButton _

        ("MyButton2", "Button 2", "This is button 2")

        m_button2.AutoHide = True

        m_miniToolbar.Controls.AddSeparator()

        m_button3 = controls.AddButton _

        ("MyButton3", "Button 3", "This is button 3")

 

        controls.AddNewLine()

 

        m_combo = controls.AddComboBox _

                  ("MyCombo", True, True, 35)

        m_combo.AddItem _

            ("Item 1", "Item number 1", , True)

        m_combo.AddItem _

            ("Item 2", "Item number 2", , False)

        m_combo.AddItem _

            ("Item 3", "Item number 3", , False)

        m_combo.AddItem _

            ("Item 4", "Item number 4", , True)

        controls.AddLabel _

            ("MyLabel", "Some stuff:", "Stuff")

 

        m_dropDown = controls.AddDropdown _

            ("MyDropdown", True, True, True)

        m_dropDown.AddItem _

            ("Thing 1", "Thing 1 tooltip", , , , )

        m_dropDown.AddItem _

            ("Thing 2", "Thing 2 tooltip")

        m_dropDown.AddItem _

            ("Thing 3", "Thing 3 tooltip", , , , )

 

        m_miniToolbar.Visible = True

 

    End Sub

When the createMiniToolbar procedure is run it will create this Mini Toolbar:

7. Now we need to add the events that will run when the user interacts with controls on the mini toolbar. In this example we are just providing feedback that the event occurred. (Note: If you try this example, the MsgBox items may be behind the Inventor Window.)

Private Sub m_button1_OnClick1() _

                      Handles m_button1.OnClick

        MsgBox("Clicked ""Button 1""")

    End Sub

 

    Private Sub m_button2_OnClick1() _

                       Handles m_button2.OnClick

        MsgBox("Clicked ""Button 2""")

    End Sub

    Private Sub m_button3_OnClick1() _

                        Handles m_button3.OnClick

        MsgBox("Clicked ""Button 3""")

    End Sub

 

    Private Sub m_combo_OnSelect1 _

   (ByVal ListItem As Inventor.MiniToolbarListItem) _

                           Handles m_combo.OnSelect

        MsgBox("Combo selected: " & ListItem.Text)

    End Sub

 

    Private Sub m_combo_OnItemHoverEnd1 _

   (ByVal ListItem As Inventor.MiniToolbarListItem) _

                      Handles m_combo.OnItemHoverEnd

        Debug.Print _

         ("Hovered ended over item """ _

                         & ListItem.Text & """")

    End Sub

 

    Private Sub m_combo_OnItemHoverStart1 _

   (ByVal ListItem As Inventor.MiniToolbarListItem) _

                     Handles m_combo.OnItemHoverStart

        Debug.Print _

           ("Hovered started over item """ _

                           & ListItem.Text & """")

    End Sub

 

    Private Sub m_combo_OnItemRemove _

   (ByVal ListItem As Inventor.MiniToolbarListItem) _

                        Handles m_combo.OnItemRemove

        MsgBox("Item removed: """ _

                             & ListItem.Text & """")

    End Sub

 

    Private Sub m_dropDown_OnSelect1 _

   (ByVal ListItem As Inventor.MiniToolbarListItem) _

                         Handles m_dropDown.OnSelect

        Debug.Print("Dropdown selected: ", _

                                     ListItem.Text)

    End Sub

 

    Private Sub m_miniToolbar_OnApply() _

                      Handles m_miniToolbar.OnApply

        MsgBox("Clicked ""Apply""")

    End Sub

 

    Private Sub m_miniToolbar_OnCancel() _

                     Handles m_miniToolbar.OnCancel

        MsgBox("Clicked ""Cancel""")

        m_miniToolbar = Nothing

        m_button1 = Nothing

        m_button2 = Nothing

        m_button3 = Nothing

        m_combo = Nothing

    End Sub

 

    Private Sub m_miniToolbar_OnOK() _

                      Handles m_miniToolbar.OnOK

        MsgBox("Clicked ""Ok""")

        m_miniToolbar = Nothing

        m_button1 = Nothing

        m_button2 = Nothing

        m_button3 = Nothing

        m_combo = Nothing

    End Sub

(End of the example)

The mini toolbars will be a nice addition to the user interface for your application. The Inventor 2012 API gives you the ability to create these floating, transparent replacements to dialog interfaces.

The API for mini toolbars Support the following:

• Apply, OK, Cancel buttons
• New lines and separators
• Button
• Check box
• Combo box
• Drop-downs

Mini toolbars are also supported within a command (InteractionEvents) and at Application level (CommandManager) as in this example.

Wayne Brill

Inventor API Labs step by step

If you are just learning the Inventor API, these webcasts delivered in the spring of 2010 are a great resource. There are labs for each section. (A slide in the presentation). The finished labs that are downloaded with the webcast recordings are very useful however the lab instructions do not have much detail.

When I do labs I usually want to have step by step instructions. If you are like me then the steps in these VB.NET projects will be better. There are four VB .NET projects in the zip file.

• Labs
• Labs_Compete
• Lab_10_AddIn_Add_To_Ribbon
• Lab_10_Complete_AddIn_Add_To_Ribbon

The Labs project creates a standalone executable that connects to Inventor from out of process. Lab_10_AddIn_Add_To_Ribbon project is an Add-In created by the SDK Add-In wizard.

Here is an example of the Instructions in the Labs project:

    ' ***** Start of LAB 2 ***********************

    ' 2.1 Add a procedure called iProps.

    ' Note: put the End Sub below step 2.19

 

    ' 2.2 Declare a variable as a PartDocument

    ' Name it m_PartDoc

 

    ' 2.3. Make a new PartDocument by using the Add

    ' method of the documents collection of the

    ' Application(variable created in step 3 of LAB1)

    ' (Instantiate the variable created in 2.2)

 

    ' 2.4. Use a For Each loop and iterate through

    ' all the PropertySets in the PartDocument

    ' created in step 2.3.

    ' Note: put the Next statement below Step 2.10

 

    ' 2.5. Use Debug.print and print the DisplayName

    ' of the PropertySet

 

    ' 2.6. Use Debug.print and print the InternalName

    ' of the PropertySet

 

    ' 2.7. Use a For Each loop and iterate through

    ' all the Property in the PropertySet created in

    ' step 2.4.(in the For Each statement)

    ' Note: put the Next statement below Step 2.10

You can use Labs_Complete if you have trouble getting the lab to work right. 

Here is a synopsis of the labs.

Lab1: Access the Application Object – Connect to an Inventor session change the ActiveView and the caption of the Inventor Window.

Lab2: iProperties - In this lab you create a procedure that creates a new part document and sets a few iProperties for the part.

Lab3: UnitsOfMeasure and parameters - Use UnitsOfMeasure to test to see if a string you get from the user is valid. If the value is valid you convert it to a different unit and use the value to update a parameter.

Lab4: WorkFeatures Sketch & Fetures - Access workaxes and workplanes. You create a new workaxis and workplane. You also create a new part, add a sketch and then extrude it. You also create a SweepFeature. (It needs a SketchLine3d)

Lab5: B-Rep: In this lab you get information about a selected edge using the curveEvaluator of the edge. You also use the B-Rep API to traverse the solid. You also use LocateUsingPoint and FindUsingRay to get geometry of the model.

Lab6: – (not finished) It would have done more with the B-Rep API

Lab7: Sheet Metal – Demonstrates the creation of sheet metal face and cut features. It creates a new sheet metal document, creates a face feature, a cut feature and another face feature. You also create a R12 DXF file.

Lab8: Assembly Occurrences - Create an assembly and place components. You will also see how to move occurrences by transforming them. This lab also has instructions for exploring proxies and how to add constraints.

Lab9: Drawings - Create an idw file and see how to add a dimension

Lab10: Add-In – Create an AddIn that adds buttons to the part and assembly ribbon. The project you complete was created by the Add-In wizard. To get your Add-In to load make sure to edit the .addin file and put the file in a location where Inventor will find it.

The instructions in these labs require some experience with VB.NET programming. If you are just getting started with programming then be sure to go through the “My First Plug-In” training first.

Wayne Brill

Program Prototyping

In some of the previous postings I've talked about some of the advantages and disadvantages of the various languages. One thing I mentioned was the use of VBA to prototype programs.  A colleague stopped by my office earlier today asking for some help with a program he's writing for a customer. Apparently the customer, and now him, have been struggling with getting the program to work. 

Here's a simplified description of what they were trying to do.  While working in a drawing that contains retrieved dimensions they want to be able to get to the associated tolerance information from the part.  I didn't immediately know the answer to this either but was able to figure it out in a couple of minutes.  The reason I was able to do this is because I know how to use VBA as a prototyping tool.  The good part is that you can learn how too. It's an extremely powerful tool when programming Inventor that you can take advantage of regardless of what language you're writing your program in. 

I'll go through the procedure step-by-step that I used to figure out the solution to this specific problem.  Although this looks at a specific case, the principles demonstrated here are generally applicable to any case.  Below is the example for this case for this case which consists of a drawing view with three retrieved dimensions.  Given a dimension we want to get the tolerance information from the associated parameter in the model.

1. Have Inventor running with the document open that contains the type of data you want to query. 
2. Select the object you're interested in.  In this case it's one of the dimensions.
3. Open the VBA environment and write the following code.  (I would write it in a module in your application project then you can use it again later.)

   Public Sub DebugObject()
       Dim oDoc As Document
       Set oDoc = ThisApplication.ActiveDocument
       Dim oObj As Object
       Set oObj = oDoc.SelectSet.Item(1)
       Stop
   End Sub

4. Run the VBA macro. You'll get an error like the one shown below if there isn't an entity selected.  Just stop the program, select the desired entity and run it again.
   
   
   
5. The macro will stop execution at the Stop statement.  (You could have also put a break in the code but the Stop statement is convenient.)
6. Right-click the mouse anywhere within the variable oObj and select the "Add Watch..." command.
   
    
   
7. Click OK and accept the defaults in the "Add Watch" dialog.
   
    
   
   
8. The Watch window should appear, if it wasn't already shown, and the variable "oObj" will be displayed. The watch window shows three interesting things; Expression, Value, and Type. The expression is the variable or property we're watching, the value is the value of that expression, and the type is the type of the variable or object the expression results in. In this example we can see the type of oObj is a DiameterGeneralDimension.  You'll often see object types prefixed with "IRx" and you can just ignore the prefix. The Value is empty because a DiameterGeneralDimension doesn't have an explicit value.
   
   
   
   
9. Click on the "+" next to oObj to expand the object. Now all of the properties of the DiameterGeneralDimension are displayed. Each property also shows it's value and type.  Some of the properties return objects and have a "+" next to them so you can expand them and see the properties associated with that object.  In this case there are two properties that are interesting for the problem we're trying to solve; Retrieved and RetrievedFrom.  The Retrieved property indicates if this drawing dimension was created by retrieving a dimension from the model.  You can see in the debug window that the value is True for the currently selected dimension.  The RetrievedFrom property returns the model dimension this was retrieved from.  In this case the type of object returned is a FeatureDimension.
   
   
   
   
10. Expanding the RetrievedFrom property you see the properties of the FeatureDimension object.  One of these is the Parameter property which returns a ModelParameter object.  Expanding this we can see the Tolerance property. Finally, expanding on this we can see the upper and lower tolerance values.  All of this is shown below.
    
    
    
    
11. Here's the corresponding code that was written based on what was learned from the debugger window.  
    
    
    Public Sub GetDimTolerance()
        ' Get the active document.  Assumes it's a drawing. 
        Dim oDrawDoc As DrawingDocument
        Set oDrawDoc = ThisApplication.ActiveDocument
    
        ' Get the selected dimension, with error handling to
        ' gracefully error out if a dimension isn't selected.
        On Error Resume Next
        Dim oDim As GeneralDimension
        Set oDim = oDrawDoc.SelectSet.Item(1)
        If Err Then
            MsgBox "A drawing dimension must be selected."
            Exit Sub
        End If 
    
        ' Check to see if the selected dimension was retrieved.
        If oDim.Retrieved Then
            ' Get the associated model dimension.
            Dim oFeatureDim As FeatureDimension
            Set oFeatureDim = oDim.RetrievedFrom
    
            ' Get the associated model tolerance.
            Dim oTol As Tolerance
            Set oTol = oDim.RetrievedFrom.Parameter.Tolerance
    
            ' Display the tolerance value.
            Debug.Print "Tol: " & oTol.Upper & "/" & oTol.Lower
        End If
    End Sub

The specifics of what the code is doing in this case isn't important but the method we used to arrived at this code is.  The debug window provides a "live" view of the object model that you can traverse through to see how objects are connected through their various properties. Anytime you want to investigate how to use the API to access a certain object or to get to particular information.

VBA Document Projects

Inventor's implementation of VBA supports two types of VBA projects; document projects and external projects.  They're defined by where the project is saved.  Document VBA projects are saved within Inventor documents, parts, assemblies, etc.  External projects are saved as individual .ivb files.  Using the File tab of the Application Options dialog you can specify one external project to be loaded automatically when Inventor starts up.  This VBA project is frequently referred to as the application project.

When VBA was integrated into Inventor we looked at other VBA integrations for ideas.  All of the applications that supported VBA that I had used at the time all used the idea of document projects so it seemed like that was something we needed to provide as part of Inventor's implementation.  However, when I had used some of these applications that only had document projects I didn't like them because it made maintaining code almost impossible.  For example, I was writing a reasonably large program in one of the applications and it was stored within a document.  I would copy that document to use the program with other sets of data.  When I wanted to make a fix or enhancement to the program I had multiple copies of it and didn't know which version of the program existed where.  As a result of this frustration we also added support for external projects in Inventor's implementation of VBA.

A feature of the document macros that Word and Excel supported that seemed good was the idea of automatic macros.  These are macros with a particular name that are run automatically when something happens in the application.  For example, when a document is opened or saved a macro is run.  This functionality makes it very easy for someone with limited programming experience to write a simple macro to respond to these events in Inventor.

A couple of releases after we added VBA to Inventor we started getting reports of some problems.  The problem turned out to be a resource issue with VBA.  People were creating document projects that used automatic macros and were using these Inventor documents that contained these projects as their templates.  That meant that every file they created had a VBA document project.  When a large assembly is loaded all of the referenced documents are also loaded, and in the case of these documents also meant loading the embedded VBA projects.  It turns out that VBA has a limit to the number of VBA projects that can be loaded.

The other significant problem to having document macros in a template is that it creates the problem I already talked about of having your program duplicated in all your documents making it very difficult to fix or enhance that program.  There is also another problem that recently came up with document projects and 64 bit Inventor.

My advice is: DO NOT USE document projects.  The one exception to this is if you're writing a program that is very specific to a single document.  For example if you have a part and write a specific program to work with only that part.  In this case it's convenient to package the program with the document rather than worry about passing an additional file with it.

External VBA projects should provide most of the functionality you would want and also provide the additional capability that you can create toolbar buttons to run the macros contained within them.  What external VBA projects don't provide is the ability to do the equivalent of automatic macros.  The best answer for this is to create an Add-In.  (There have been some Add-In utilities written that add support for automatic macros to VBA external projects but I've found for most people that these end up being confusing because they don't understand how they work and as a result don't know how to debug and diagnose problems when they occur.)  An Add-In allows you to do anything you could do in VBA and more.  The downside of an Add-In is that there's a higher learning curve to getting started.

In my next posting I'll cover what's required to create an Add-In that replaces an existing automatic macro.

Inventor API Fundamentals 004 - Connecting to the API

In the last posting I discussed the object model and that it provides a structured way to access the various objects that make up Inventor’s API. In order to use the object model you need to do two things; reference the library that describes Inventor’s object model and gain access to the Application object. (The Application object is the top-most object in the object model and through it you can access all the other objects.)

How you reference the API and access the Application object will differ slightly for the different languages. These are discussed below along with example code that demonstrates getting the Application object and calling its Caption property.

Inventor’s VBA
Because the VBA that’s delivered with Inventor is integrated with Inventor, it provides the easiest access to Inventor’s object model. In Inventor's VBA, the Inventor API library is already referenced and it provides an easy way of accessing the Application object by providing a global property called ThisApplication, which returns the Application object. All you need to display Inventor’s caption with Inventor’s VBA is the code below.

MsgBox ThisApplication.Caption

External Application
External Application refers to any application that runs outside of Inventor.  Typically these are Windows applications (.exe programs) but this also includes VBA programs written using VBA in another application (i.e. Word or Excel).  This term does not refer to Add-In applications.

How you Reference Inventor’s API varies for each of the programming environments and is discussed below for each one. The mechanics of gaining access to the Application object also varies with the different programming languages; however, for all languages there are two basic ways to connect. The first is to see if Inventor is running and get the Application object associated with it. The second is to start Inventor and get the associated Application object. Both are useful and which one to use depends on what you’re trying to accomplish. Connecting to a running instance of Inventor is probably the most common. Starting Inventor is common for batch processing types of programs.

VBA / VB 6
Referencing the API
Use the “References…” command (in the Tools menu in VBA and the Project menu in VB 6) to add a reference to Inventor’s object library, as shown below.

Referencing the Inventor Object Library in VBA and VB 6.

Connecting to a Running Instance of Inventor

Dim inventorApp As Inventor.Application

' Attempt to get a reference to a running instance of Inventor.
On Error Resume Next
Set inventorApp = GetObject(, "Inventor.Application")
If Err Then
    MsgBox "Inventor must be running."
    Exit Sub
End If
On Error GoTo 0

MsgBox inventorApp.Caption

Starting an Instance of Inventor

Dim inventorApp As Inventor.Application

On Error Resume Next
Set inventorApp = CreateObject("Inventor.Application")
If Err Then
    MsgBox "Error starting Inventor."
    Exit Sub
End If
On Error GoTo 0

' Make Inventor visible.
inventorApp.Visible = True

MsgBox inventorApp.Caption

VB.Net
Referencing the API
The .Net languages use something called an interop assembly to be able to call a COM Automation API. With Inventor 2009, Inventor installs an interop assembly (Primary Interop Assembly or PIA) for all developers to use. You reference this into your application using the “Add Reference…” command and selecting Autodesk.Inventor.Interop from the .Net tab as shown below.

Referencing the Inventor Object Library in VB.Net

For versions of Inventor previous to Inventor 2009 you need to select “Autodesk Inventor Object Library” from the COM tab of the Add Reference dialog. This will generate a local interop assembly for your project.

Referencing the Inventor Object Library in VB.Net (Inventor 2008 and earlier)

Connecting to a Running Instance of Inventor
The VBA / VB6 code above will work in VB.Net, but VB.Net also provides the try catch style of error handling which is usually nicer than the older On Error error handling.

Dim inventorApp As Inventor.Application

' Attempt to get a reference to a running instance of Inventor.
Try
    inventorApp = GetObject(, "Inventor.Application")
Catch ex As Exception
    MsgBox("Inventor must be running.")
    Exit Sub
End Try

MsgBox(inventorApp.Caption)

Starting an Instance of Inventor

Dim inventorApp As Inventor.Application
Try
    inventorApp = CreateObject("Inventor.Application")
Catch ex As Exception
    MsgBox("Error starting Inventor.")
    Exit Sub
End Try

inventorApp.Visible = True

MsgBox(inventorApp.Caption)

C#
Referencing the API
Referencing the API in a C# application is exactly the same as for Visual Basic and the instructions above apply.  You'll need to add the following to the top of your project.

using System.Runtime.InteropServices;

Connecting to a Running Instance of Inventor

Inventor.Application inventorApp = null
try
{
   // Attempt to get a reference to a running instance of Inventor.
   inventorApp =(Inventor.Application)Marshal.GetActiveObject("Inventor.Application");
}
catch

{
   MessageBox.Show("Unable to connect to Inventor.")
   return;
}

MessageBox.Show(inventorApp.Caption);

Starting an Instance of Inventor

Inventor.Application inventorApp = null;

try
{
   // Start Inventor.
   System.Type oType = System.Type.GetTypeFromProgID("Inventor.Application");
   inventorApp = (Inventor.Application)System.Activator.CreateInstance(oType);

   // Make Inventor visible.
   inventorApp.Visible = true;
}
catch
{
   MessageBox.Show("Unable to start Inventor.");
   return
}

MessageBox.Show(inventorApp.Caption);

 

Visual C++
Referencing the API
Referencing the API for an unmanaged VC++ project is done by including a header file provided by Inventor’s SDK. This header file imports Inventor’s object library and includes some other useful header files.

#include "InventorUtils.h"

Connecting to a Running Instance of Inventor
There are different flavors of VC++ (managed and unmanaged) and different ways to use Inventor’s API from VC++. The samples below represent one style.

HRESULT Result = NOERROR;

CLSID inventorClsid;
Result = CLSIDFromProgID (L"Inventor.Application", &inventorClsid);
if (FAILED(Result)) return Result;

CComPtr pInventorAppUknown;
Result = ::GetActiveObject (inventorClsid, NULL, &pInventorAppUknown);
if (FAILED (Result)){
   MessageBox(0, _T("Could not connect to Inventor."), _T("Error"), 0);
   return Result;
}

// QueryInterface for the Inventor Application object.
CComPtr pInventorApp;
Result = pInventorAppUknown->QueryInterface(__uuidof(Application),
                                           (void **) &pInventorApp);
if (FAILED(Result)) return Result;
// Get and display the caption.
CComBSTR bstrCaption;
Result = pInventorApp->get_Caption(&bstrCaption);
if (SUCCEEDED(Result))
   MessageBox(0, bstrCaption, _T("Inventor Caption"), 0);

Starting an Instance of Inventor

HRESULT Result = NOERROR;

CLSID inventorClsid;
Result = CLSIDFromProgID (L"Inventor.Application", &inventorClsid);
if (FAILED(Result)) return Result;

CComPtr pInventorAppUknown;
Result = CoCreateInstance(inventorClsid, NULL, CLSCTX_LOCAL_SERVER,
                  __uuidof(IUnknown), (void **) &pInventorAppUknown);
if (FAILED (Result)) {
   MessageBox(0, _T("Could not start Inventor."), _T("Error"), 0);
   return Result;
}

// QueryInterface for the Inventor Application object.
CComPtr pInventorApp;
Result = pInventorAppUknown->QueryInterface(__uuidof(Application),
                                           (void **) &pInventorApp);
if (FAILED(Result)) return Result;

// Make Inventor visible.
pInventorApp->Visible = VARIANT_TRUE;

// Get and display the caption.
CComBSTR bstrCaption;
Result = pInventorApp->get_Caption(&bstrCaption);
if (SUCCEEDED(Result))
   MessageBox(0, bstrCaption, _T("Inventor Caption"), 0);

Inventor API Fundamentals 003 - The Object Model

As discussed in the previous post , Inventor exposes its programming interface using COM Automation technology. A COM Automation interface is an object oriented type of interface. This means the API defines a set of objects and these objects have various functions (methods and properties) that allow you to query, edit, and create new objects.  For Inventor’s API, most of the API objects will already be familiar to you because they represent the same things you’re working with when you use Inventor interactively, (which is why it's important to have a good knowledge of Inventor before attempting to use the API). For example, in the API there is a Parameter object that represents a parameter in a part or assembly. The Parameter object supports methods and properties that allows you to query and edit the parameter it represents.  For example, a Parameter object has a property called Name that will return the name of the parameter and you can set the value of the property to change the name of the parameter.

The Object Model is an important concept to understand in order user the API. The API objects are linked together in a logical way. In order to get a certain object you need to understand how they're linked because you'll need to go from one object to another to get to a specific object. The structure of the objects is referred to as the object model. The object model is typically represented as a hierarchal chart that shows the relationship between objects. If you’re familiar with C++ class diagrams, this IS NOT the same as that. It does not show a class hierarchy but illustrates an ownership hierarchy.  For example, a dimension constraint is owned by a sketch, it's not derived from the sketch.  If you have a reference to an API object you should be able to traverse the object model to access any other object as long as you understand the structure of the object model.

There are a few tools available to help you view and understand this object model:

• Object Model Chart – This is a chart that illustrates the object hierarchy. It’s most useful in a hard copy form because of it's size it's hard to view on a computer screen. Initially, it can look a bit overwhelming because there are so many objects but because you’ll typically just be using a few objects within a certain area of the API you'll end up learning it in small pieces.

  
  Object Model Chart (click to expand in a new window)

  This chart is delivered as part of the Inventor API SDK (Software Development Kit) but you can also download it here.

• Online Help – Part of the programming help that’s delivered with Inventor contains a description of every object along with details about the methods, properties, and events each object supports. You access the programming help from the Help menu in Inventor.

  
  Inventor API Programming Help (click to expand in a new window)

• Object Browser – The object browser is a user-interface for viewing the objects and their associated methods and properties. Object browsers exist in various forms in the different languages but the object browser that's part of VBA is probably the best for viewing Inventor's objects. From within VBA you show the object browser by running the Object Browser command (F2). The drop-down in the upper-left of the Object Browser dialog lets you choose which programming library you want to view. The field below that allows you to search the library.  The dialog contains two main areas. The one of the left is a list of all of the objects in the selected library. When you select an object, the area on the right shows the methods and properties of that object. Selecting a method or property will display specific information about it at the bottom of the dialog.

  
  VBA Object Browser (click to expand in a new window)

• VBA Debugger – The VBA debugger is also useful outside of the normal context of debugging a program. Because of VBA’s support of COM Automation it allows you to examine live objects and their properties while traversing through multiple levels of the object model. This is an extremely powerful and useful tool no matter what language you’re using, and well worth learning how to use.
  
  If you're unfamiliar with debugging in VBA, here's a crash course.

  1. Have Inventor running and a part open that contains a few features.
  2. Open Inventor's VBA development environment (Alt-F11).
  3. Double-click on a module in a project to open a code window.  In the picture below it's Module1 from the ApplicationProject.
  4. Create the Sub as shown in the picture below.
  5. Position the cursor anywhere within the Sub you just wrote and press F8 to start debugging.
  6. Right-click the mouse over ThisApplication and choose "Add Watch..." from the context menu.  Click OK on the Add Watch dialog.

      
     Using the VBA Debugger (click to expand in a new window)

  7. VBA will open the Watches window with the variable you selected displayed in the window, as shown below.  The object shown in this example is the Application object.  The Application object represents the entire Inventor application and is the top most object in the object model.  You can click the "+" next to the name to expand the object to show its properties.  Each property shows its current value, or if the property returns another object it will have a "+" next to it.  You can traverse through the hierarchy by expanding the plus signs.
     
     This provides a live view of the object model.  In the example below, the ActiveDocument property is expanded to show the currently active document.  For a part, most of the interesting information is contained within an object called PartComponentDefinition which is returned by the ComponentDefinition property of the PartDocument. You'll see this object provides access to parameters, features, and other part related objects. Playing with this, along with the object model chart, you can get a better understanding of the object model.

      
     VBA Watch Window (click to expand in a new window)

Inventor API Fundamentals 002 - Choosing a Language

To program Inventor you need to use some type of programming language.  The good and the bad news is that there are a lot of choices.  It’s good because it provides flexibility for everyone to choose something they like and best fits their requirements.  It’s bad because you have to make a choice and if you’re new to all of this you may not know what to look for in making that choice.  Discussing computer languages can be a dangerous topic because people tend to have strong opinions and can be passionate about their language of choice.  In reading any of the following, just remember that it’s my opinion. 
For learning Inventor’s API, I believe you should use Inventor's VBA (Visual Basic for Applications).  I’m not saying it’s the best language to use when writing applications for Inventor, but I think it is the best for learning and experimenting with the API.

When programming Inventor, Inventor doesn’t care which language you use.  Inventor exposes its programming interface using Microsoft technology called COM Automation.  This technology provides a formalized way to describe the details of a programming interface in a generic way.  When you call an Inventor API function the call goes through this Automation interface and when Inventor receives the call it doesn’t even know what programming language the call came from.  The only language requirement when programming Inventor is that it supports COM Automation, which most languages do.

My reason for recommending VBA is because VBA was designed specifically for programming COM Automation interfaces.  Because of this there are two big advantages to using VBA; the Object Browser and debugging.  The Object Browser is a tool within VBA that allows you to look at the objects and functions provided by an API.  Other languages also provide object browsing functionality but they don’t work as well as the VBA browser for viewing COM Automation interfaces.  As far as debugging, almost all languages support the ability to debug your programs; however VBA supports better debugging a COM Automation interface by allowing you to view more details about objects.  Another point in VBA’s favor is that’s it integrated with Inventor, which means if you have Inventor you have VBA.  This integration also makes it easier to access Inventor’s API than when using any other language.  One other advantage is that the API samples in the online help are currently all written in VBA.

All of the reasons I’ve listed above make VBA an easier language to use when learning the API and even later when prototyping and investigating the capabilities of the API.  No matter what your programming experience and language preferences I highly recommend gaining a basic understanding of VBA because I believe it will benefit your overall programming efficiency when programming Inventor’s API.  You can think of VBA as a style of pseudo-code that you can run and test.  The API principles you learn with VBA aren't language specific and are easily transferred to any other language.

Even with the advantages of using VBA discussed above, I don’t recommend VBA for writing an Application.  It's ok for small macros but for larger work there are better choices.  All languages have pros and cons and VBA’s cons don’t make it the best language for writing applications.  My current personal choice for writing applications is Visual Basic .Net, which Visual Basic 2008 is the most current version.  My choice of Visual Basic over most of the other available languages is primarily personal preference but there are a couple of reasons I would also recommend it to a newer programmer.  First, it provides an easier upgrade path from VBA and second, I believe it is easier to use than the other languages.

One version of Visual Basic worth spending a little time discussing here is Visual Basic 6.  Many of the existing larger samples provided with Inventor's SDK were written using VB 6.  This is an older version of the Visual Basic language and has many of the same advantages as VBA since it uses the same underlying engine.  It was made to program COM Automation types of programming interfaces and has the same object browser and debugging support that VBA has.  A big problem with VB 6 is that it has been discontinued and is no longer available from Microsoft.  It also does not support writing applications for 64 bit Windows.  If you’re going to make the effort to learn a programming language it doesn’t seem very good to spend your time learning and writing a lot of code with an obsolete language.  Becuase of that I can’t recommend using VB 6.

The .Net languages, C# and Visual Basic, both support COM Automation programming.  Even though they both have the object browser tool and support debugging they don't work as well as they do in VBA. However, they have a lot of other advantages over VBA (and VB 6) that makes them a better choice for larger application development.  Whether you choose Visual Basic or C# is really just personal preference.

The other popular language, primarily with professional developers, is Visual C++.  Visual C++ is a very powerful language but is also difficult to learn and use.  It supports programming a COM Automation interface but is significantly harder than either Visual Basic or C# to use.  If you choose to use Visual C++ you can expect a higher learning curve and longer development times.

Finally, there are a few fringe languages.  Some of these have been around for a long time, (i.e. Delphi), and others are relatively new (i.e. Python).  As I said earlier, Inventor doesn’t know or care what language you’re using and you can use whatever you choose.  However, you’ll have a hard time finding any samples or support when using these languages.  For me, they’re interesting to look at but at this point I would be hesitant to begin a large development project using any of them.

No matter what language you choose I still recommend using VBA for prototyping investigating the API.  For the rest of this series of articles I’ll be using VBA to demonstrate the use of the API.  Where there are actual differences when using other languages with Inventor’s API, I’ll try and have code that demonstrates those differences and what’s needed in the various languages to get things to work.

Inventor API Fundamentals 001 - Getting Started

I plan on having a series of posts that are intended for those of you that are new to programming and/or Inventor's programming interface and want to get started writing programs for Inventor.  I'll also break in on the series occasionally with various other topics that are usually more advanced or that I find interesting at the moment.  This post is the first in the getting started series.  Here is the process I would suggest for anyone wanting to program Inventor.

1. Learn how to use Inventor interactively.  This is more important than you might think.  Most of Inventor’s programming interface is just an alternative way of doing the same things you do interactively through the user-interface.  For example, if you create an extrude feature through the user-interface you see the required input; profile, solid or surface output, operation, extent information, and taper angle.  You supply all of this information through the Extrude dialog and by interacting with the model.  To create an Extrude through the API you call a method that has exactly the same type of input.  The same set of information is being gathered by both the command (user-interface) and the programming interface and then both interfaces end up calling the same internal function to create the actual extrusion.
   
   Understanding how Inventor works and the requirements for the various commands is easiest to learn through the user-interface.  Since these same concepts also apply when using the programming interface it will make learning the programming interface much easier.
   
   
2. Choose and learn a programming language.  To effectively program you need to have a basic understanding of the programming language you’re using.  To effectively customize Inventor you DO NOT need to be an expert in that language.  Any language has a lot of features and intricacies that you could spend more time than most of us have learning them.  A basic understanding of the language should be enough.  In my next posting I’ll discuss several different languages and the pros and cons of each.
   
   
3. Begin learning Inventor’s programming interface.  There are some basic concepts to learn to get started and then you can expand into different functional areas of Inventor.  You don’t need to learn the entire API at once.  Looking at different areas of the Inventor's API will be a running theme of this blog. 

So, for now just keep working with Inventor and we’ll look at programming languages next time.