Manufacturing DevBlog

Managing Model States Edit Scope in Autodesk Inventor 2026 API

by Chandra shekar Gopal,

When working with Model States in Autodesk Inventor, controlling which states are actively being edited becomes crucial—especially when automating complex design workflows. The Inventor API provides powerful control through two key properties:

• MemberEditScope
• ModelStatesInEdit

This article explains how to use these features to manage model states programmatically in Autodesk Inventor 2026, which introduces an important enhancement:

🔧 Inventor 2026 now allows write access to ModelStatesInEdit, enabling developers to directly modify which model states are in edit mode—something not supported in earlier versions.

---

🧩 Understanding MemberEditScope

The MemberEditScope property determines which model states are affected during an edit operation. It can be one of the following:

Constant	Description
kEditActiveMember	Only the currently active model state is edited.
kEditAllMembers	All model states are edited.
kEditMultipleMembers	Multiple (but not all) model states are in edit mode.

Note: If MemberEditScope returns kEditMultipleMembers, use ModelStatesInEdit to identify the specific model states being edited.

---

🎯 Understanding ModelStatesInEdit

The ModelStatesInEdit property is a read/write collection that explicitly lists which model states are in edit mode.

Behavior Rules:

• If it contains only the active model state → MemberEditScope = kEditActiveMember
• If it contains all model states → MemberEditScope = kEditAllMembers
• If it includes the active model state plus others → MemberEditScope = kEditMultipleMembers

✅ Best Practice: Always include the active model state when assigning ModelStatesInEdit.

---

🔍 Example 1: Print the Current MemberEditScope

Sub PrintEditScope()
    Dim modelStates As ModelStates
    Set modelStates = ThisApplication.ActiveDocument.ComponentDefinition.modelStates

    Select Case modelStates.MemberEditScope
        Case kEditActiveMember
            Debug.Print "kEditActiveMember"
        Case kEditAllMembers
            Debug.Print "kEditAllMembers"
        Case kEditMultipleMembers
            Debug.Print "kEditMultipleMembers"
    End Select
End Sub

Output Illustration – Example 1

---

📃 Example 2: List Model States in Edit Mode

Sub PrintModelStatesInEdit()
    Dim modelStates As ModelStates
    Set modelStates = ThisApplication.ActiveDocument.ComponentDefinition.modelStates

    Dim inEdit As ObjectCollection
    Set inEdit = modelStates.ModelStatesInEdit

    Dim ms As ModelState
    For Each ms In inEdit
        Debug.Print ms.Name
    Next
End Sub

---

✏️ Example 3: Modify the Model States in Edit Mode (New in Inventor 2026)

Thanks to Inventor 2026, we can now dynamically update which model states are in edit mode programmatically:

Sub ModifyMultipleModelStatesSample()
    Dim oModelStates As ModelStates
    Set oModelStates = ThisApplication.ActiveDocument.ComponentDefinition.modelStates

    Dim oCol As ObjectCollection
    Set oCol = ThisApplication.TransientObjects.CreateObjectCollection

    ' Activate Model State 2
    Dim oMS As ModelState
    Set oMS = oModelStates.Item(2)
    oMS.Activate

    ' Include ModelState2 to ModelState4 in edit mode
    Dim i As Integer
    For i = 2 To 4
        oCol.Add oModelStates.Item(i)
    Next i

    oModelStates.ModelStatesInEdit = oCol
End Sub

Output Illustration – Example 3

🔄 Before and After:

• Before running: Only Model State 1 is in edit mode.
• After running:
  • Model State 2 becomes active.
  • Model States 2, 3, and 4 are now in edit mode.

---

🔑 Key Takeaways

• MemberEditScope defines how many model states are being edited.
• ModelStatesInEdit gives precise control over which model states are in edit mode.
• Inventor 2026 enhances this by allowing write access to ModelStatesInEdit.
• Always include the active model state when modifying the collection.
• Use these properties to automate configuration-driven modeling scenarios.

---

💡 Why This Matters

Model States are essential for representing different design variants or manufacturing stages within a single Inventor file. Controlling how and which states are edited programmatically is vital for:

• Efficient model management
• Automating large assemblies
• Dynamically generating manufacturing configurations

By leveraging MemberEditScope and the new write-enabled ModelStatesInEdit in Inventor 2026, you gain full control over your Inventor automation workflows.

The Relationship Between iProperties and Model States in Autodesk Inventor 2026 API

by Chandra shekar Gopal,

iProperties and Model States are two key features in Autodesk Inventor that streamline workflows, enhance customization, and optimize performance. In this blog, we’ll dive into these two features and explore how they work together to improve the design and manufacturing process.

What Are iProperties?

In Autodesk Inventor, iProperties are a core feature that provides essential metadata for parts and assemblies. These properties can include part numbers, materials, descriptions, and even custom user-defined fields. Through the Inventor API, you can access, modify, and automate these properties to ensure consistency throughout the design and streamline the documentation process.

Why iProperties Matter

iProperties reduce the need for manual input and the risk of errors, which is especially valuable when working with large, intricate designs. They also allow for seamless integration with business systems like ERP (Enterprise Resource Planning) and PLM (Product Lifecycle Management), ensuring that design data flows smoothly across production stages. By automating the assignment of properties, iProperties help improve the efficiency and accuracy of your designs.

Key Benefits of iProperties:

• Automation: Automatically assign and update properties across parts and assemblies.
• Customization: Tailor property sets to meet the unique requirements of your project.
• Integration: Link design metadata to external systems, ensuring consistency across workflows.
• Simplified Management: Streamline data management, particularly for large assemblies and complex designs.

With iProperties, Autodesk Inventor users can efficiently handle metadata, reducing complexity in both design and manufacturing processes.

What Are Model States?

Model States, introduced in Inventor 2022, provide a new workflow that allows users to create multiple configurations or variations of a part or assembly within a single file. This feature simplifies managing different stages of manufacturing, product simplifications, or creating flexible product families—without needing separate files for each configuration.

Why Model States Matter

Model States provide greater control over your designs by enabling different configurations with varying dimensions, features, components, iProperties, and BOM (Bill of Materials). This not only optimizes performance, especially for large assemblies, by allowing components to be suppressed and memory usage to be reduced but also improves the documentation process. Model States capture various configurations or stages in a design, ensuring accurate representations throughout the design lifecycle.

Key Features of Model States:

• Multiple Configurations: Create different variations of parts or assemblies within a single file.
• Performance Optimization: Suppress components and reduce memory usage, improving overall performance.
• Customization: Modify features, dimensions, and components in each Model State to suit different design iterations.
• Collaboration: Work with multiple instances of the same part in different states within an assembly.
• Integration with Representations: Seamlessly integrate with other representations like View and Positional Representations to enhance flexibility.

With Model States, Inventor users can manage complex configurations more efficiently, all within a single file.

Key Concepts Related to Model States

To fully appreciate the interaction between iProperties and Model States, it’s important to understand some key concepts related to Model States:

1. Model States

Model States allow users to create different configurations or variations of a part or assembly within a single file. These configurations can include variations in features, components, iProperties, and BOM. Through the Inventor API, different Model States can be activated to set or retrieve property values, demonstrating how iProperties can be tied to specific states of the model. This enables users to manage complex designs in a more streamlined and organized manner.

New in Inventor 2026:

The ModelStates.ModelStatesInEdit property has been introduced to get or set the Model States that are currently in edit mode. This allows developers to more precisely control which states are being modified during automation. When using this property, the MemberEditScope will return kEditMultipleMembers, confirming that multiple states are active for editing. This enhancement greatly expands flexibility when working across several Model States at once.

2. MemberEditScope

The MemberEditScope is a critical concept when working with Model States (For more info, refer this documentation link - Autodesk Inventor MemberEditScope). It determines whether edits are applied to only the active member (the currently selected configuration) or to all members in a multi-member model. By setting the MemberEditScope to kEditActiveMember, changes are isolated to the active Model State, preventing unintended modifications to other configurations. This concept allows users to make precise edits to specific configurations without affecting the entire model.

Complementary to this, the new ModelStatesInEdit capability in Inventor 2026 makes it easier to switch between editing single or multiple members programmatically—helpful when updating shared metadata like iProperties across selected configurations.

3. Global vs. Local Properties

Model States can include both global and local properties. Global properties affect all Model States, while local properties are specific to the active Model State. In the provided code, certain iProperties (such as "Title" or "Subject") can be modified either globally or locally, depending on how the Model State is activated. Understanding the distinction between global and local properties is essential for managing how changes are applied across different configurations.

Note: Properties include iProperty, BOM (BOM structure), etc.

The Power of iProperties and Model States Together

When iProperties and Model States are used together, they significantly enhance Autodesk Inventor’s capabilities. iProperties handle document metadata, while Model States manage design configurations, stages, and performance optimizations. Together, these features help streamline workflows, improve collaboration, and provide customization across large assemblies and complex designs.

Let’s explore some code examples that demonstrate how iProperties and Model States work in the Autodesk Inventor API.

Sample Code Walkthrough

1. Setting iProperties in Different Model States

This example demonstrates how to modify iProperties for a specific Model State while isolating the changes to the active member. The code below changes the "Title" iProperty within the second Model State and isolates the change to that specific state by setting the MemberEditScope to kEditActiveMember.

Sub prop1_SetFromPropWithOthers()

    Dim oDoc As PartDocument
    Set oDoc = ThisApplication.ActiveDocument
    
    Debug.Print oDoc.ComponentDefinition.ModelStates.MemberEditScope
    
    oDoc.ComponentDefinition.ModelStates.MemberEditScope = kEditActiveMember
    oDoc.ComponentDefinition.ModelStates.Item(2).Activate
    oDoc.PropertySets.Item(1).Item("Title").Value = "SetToOthers"
    
    Debug.Print oDoc.FilePropertySets.Item(1).Item("Title").Value
End Sub

2. Propagating iProperties Across All Model States

Here, the "Subject" iProperty is updated globally across all Model States. The example below shows how properties not part of the Model State Table, like global properties, can propagate across all Model States.

Sub prop2_NotInTable_Global()

    Dim oDoc As PartDocument
    Set oDoc = ThisApplication.ActiveDocument
    
    Debug.Print oDoc.ComponentDefinition.ModelStates.MemberEditScope

    oDoc.ComponentDefinition.ModelStates.MemberEditScope = kEditActiveMember
    oDoc.ComponentDefinition.ModelStates.Item(2).Activate
    oDoc.FilePropertySets.Item(1).Item("Title").Value = "Set77"
    
    Debug.Print oDoc.FilePropertySets.Item(1).Item("Title").Value

    'Not in table property
    oDoc.FilePropertySets.Item(1).Item("Subject").Value = "Should behave global2"
    Dim oMS As ModelState

    For Each oMS In oDoc.ComponentDefinition.ModelStates
        oMS.Activate
        Debug.Print oMS.Document.PropertySets.Item(1).Item("Subject").Value
    Next

End Sub

3. Modifying Properties Across Occurrences

In assembly documents, you can modify properties of part occurrences. The code below updates the "Date Checked" property for a part document accessed through an assembly occurrence, ensuring the update is reflected across all Model States.

Sub prop3_Occ1_ChangeMember_Global()

    Dim oAssyDoc As AssemblyDocument
    Set oAssyDoc = ThisApplication.ActiveDocument

    Dim oDoc As PartDocument
    Set oDoc = oAssyDoc.ComponentDefinition.Occurrences(1).Definition.Document

    oDoc.FilePropertySets.Item(3).Item("Date Checked").Value = "2/1/2020"

    Dim oFacDoc As PartDocument
    Set oFacDoc = ThisApplication.Documents.Open(oDoc.FullFileName)

    For Each oMS In oDoc.ComponentDefinition.ModelStates
        Debug.Print oMS.Document.FilePropertySets.Item(3).Item("Date Checked").Value
    Next
    oFacDoc.Close True

End Sub

Conclusion

Both iProperties and Model States in Autodesk Inventor play pivotal roles in enhancing the efficiency and flexibility of design and manufacturing workflows. iProperties help automate metadata management, reduce errors, and integrate seamlessly with external systems like ERP and PLM. Meanwhile, Model States allow users to manage different configurations, optimize performance, and simplify the handling of complex designs—all within a single file.

With the addition of the ModelStatesInEdit property in Inventor 2026, users now have granular control over which Model States are in edit mode—enabling more advanced automation scenarios and bulk updates across multiple configurations with confidence.

By understanding key concepts like Model States, MemberEditScope, and the differences between global and local properties, Inventor users can take full advantage of these features to streamline their design processes, improve collaboration, and create highly customizable product configurations without the need for multiple files.

The combination of iProperties and Model States in Autodesk Inventor provides a robust, efficient, and scalable solution for managing intricate 3D designs and manufacturing workflows.

Migrating add-in to latest product version

In the case of Inventor for many years the migration effort has been rather low - often you didn't even have to touch your add-in, it just worked with the new release as well.

Every now and then, however, we introduce changes that require testing and even rethink of certain parts of the code.

One such big change was moving from LOD (Level Of Detail) in Inventor 2021 to Model States in Inventor 2022. The changes not only affected code directly working with LOD, but other parts too:
Porting guide from Level of Details to Model states

Now we had another one: moving from .NET Framework 4.8 in Inventor 2024 to .NET 8 in Inventor 2025 - other products like Vault did the same.
If you are relying on libraries that do not work with .NET 8, that can be a problem.
It's worth checking, however, if your existing .NET Framework 4.8 add-in works with Inventor 2025 - it might, which could give you some extra time to migrate.
Autodesk Desktop API Updates: .NET Core 8.0 Migration | Webinar recording
Autodesk Vault 2025 SDK – Breaking News

If you are going from Inventor 2021 (or before) to Inventor 2025 you'll have to deal with both changes at the same time, which could be a big effort.

The bottom line of all the above is that Inventor developers should be testing their add-in in the latest versions, and don't just assume or hope that things will work.
You can get ahead of things by testing your add-in with Inventor betas and release candidates available on the feedback site, months before the final product is published. 

In general with Autodesk add-in and plug-ins it's very important to plan for migration activities before rolling out the tools in a large production environment. Without adequate testing in a "sandbox" environment, you can end up with incompatibilities and other issues after the rollout. 

The API documentation contains a What's New section that can be a good starting point when migrating to the new release. In the case of Inventor 2025 you can find it here.
You can find the same for Vault 2025 here - if you have developed solutions for that, those too should be tested for each new release.

If you're an ADN member then you can get additional licenses for development purposes at no extra cost which could also be useful to create a dedicated testing environment.

How to Add Child Controls to the Context Menu in Autodesk Inventor

by Chandra shekar Gopal,

In Autodesk Inventor, customizing the context menu (the right-click menu) can significantly enhance user experience by adding commonly used commands or custom tools. However, there is no direct method currently available for adding child controls directly to the context menu. While this functionality isn't natively supported, there is a workaround using VBA (Visual Basic for Applications) to achieve this.

In this blog, we will walk through the steps and code required to add child controls (such as "Update", "Delete", and "Copy") to the context menu in Autodesk Inventor.

---

The Workaround: Using VBA to Add Child Controls to the Context Menu

Although there isn’t a built-in option for directly adding child controls to the context menu, you can work around this by creating a custom command bar and populating it with buttons. You can then add this custom command bar as a popup to the existing context menu.

Here’s a simple guide to implement this workaround:

Step 1: Initialize the User Input Events

In your VBA code, you need to start by initializing the UserInputEvents object, which listens for user actions, including the context menu interaction.

Private WithEvents UIE As UserInputEvents

Public Sub Init()
    Set UIE = ThisApplication.CommandManager.UserInputEvents

    Do
        DoEvents
    Loop
End Sub

Step 2: Handling the Context Menu

Next, you can use the UIE_OnContextMenu event to handle the right-click event and add the custom controls to the context menu. In this example, we are creating a custom command bar (called "CustomBar") and populating it with buttons.

Private Sub UIE_OnContextMenu(ByVal SelectionDevice As SelectionDeviceEnum, ByVal AdditionalInfo As NameValueMap, ByVal CommandBar As CommandBar)
    Dim oBar As CommandBar

    On Error Resume Next
    Set oBar = ThisApplication.UserInterfaceManager.CommandBars("CustomBar")
    oBar.Delete ' Delete any existing "CustomBar"

    Set oBar = ThisApplication.UserInterfaceManager.CommandBars.Add("CustomBar", "CustomBar", kPopUpCommandBar)
    On Error GoTo 0

    ' Adding child controls (buttons)
    oBar.Controls.AddButton ThisApplication.CommandManager.ControlDefinitions("AppLocalUpdateCmd")
    oBar.Controls.AddButton ThisApplication.CommandManager.ControlDefinitions("AppDeleteCmd")
    oBar.Controls.AddButton ThisApplication.CommandManager.ControlDefinitions("AppCopyCmd")

    ' Add the custom bar as a popup in the context menu
    CommandBar.Controls.AddPopup oBar
End Sub

Step 3: Running the Code

Once the VBA code is executed, a custom command bar named "CustomBar" will be added to the context menu with the following child controls:

• Update
• Delete
• Copy

This setup allows you to extend the context menu with additional functionality that can be customized according to your needs.

Here’s what the context menu would look like after the code runs (as shown in the image below):

Conclusion

While Autodesk Inventor does not currently provide a direct method to add child controls to the context menu, this workaround using VBA allows you to create custom command bars and enhance the user interface with added functionality. With this method, you can improve your workflow by providing quick access to commands like Update, Delete, and Copy right from the context menu.

As always, keep an eye on Autodesk’s updates, as future releases may provide a more native way to handle this customization, making it easier to implement in your applications.

Understanding STL Translator Options and Value Types in Inventor API

by Chandra shekar Gopal,

When exporting files to STL format in Autodesk Inventor, users often come across different translator options. These include Surface Deviation, Normal Deviation, MaxEdgeLength, and Aspect Ratio, which are important parameters in defining the quality of the exported STL file. However, a common question that arises is the discrepancy between how these options are represented in the Inventor UI and how they are handled through the Inventor API.

The Question

In the Inventor User Interface (UI), the STL translator options—Surface Deviation, Normal Deviation, MaxEdgeLength, and Aspect Ratio—are accepted as double values. This means that you can input values with decimal precision for fine-tuning the export options, as shown in the UI settings.

However, the Inventor API documentation mentions that these same STL translator options are expected to be in integer format. This raises confusion, especially when developers are trying to pass these values through the API for automation or custom applications.

For clarity, here’s how the translator options and their expected value types are represented in the Inventor API documentation:

The Answer: Converting Double to Integer

To resolve the confusion, it is important to understand how the Inventor API processes these values. Typically, the STL translator internally converts the integer values to double types by dividing the integer value by 100.0. This approach allows for greater precision in the final output while still adhering to the integer input requirement in the API.

For example, if you input a value of 2000 for the Aspect Ratio in the API, it will be internally converted to 20.00 when applied in the STL translator. Additionally, if the input value exceeds the valid range, the translator will automatically default to the maximum allowable value (21.5).

Default Values and Resolution Settings

The Inventor API provides default values for different resolutions, which allow you to specify the level of detail in the exported STL file. These resolution settings are divided into High, Medium, and Low categories, as shown in the code snippet below:

// High resolution defaults
const int HIGH_SUR_DEV = 5;
const int HIGH_NOR_DEV = 1000; // (10 degrees)
const int HIGH_MAX_EDGE_LEN = MAX_EDGE_LENGTH_SLIDER_MAX; // (100.0)
const int HIGH_ASPECT_RATIO = ASPECT_RATIO_SLIDER_MAX; // (21.5)

// Medium resolution defaults
const int MEDI_SUR_DEV = 16;
const int MEDI_NOR_DEV = 1500; // (15 degrees)
const int MEDI_MAX_EDGE_LEN = MAX_EDGE_LENGTH_SLIDER_MAX; // (100.0)
const int MEDI_ASPECT_RATIO = ASPECT_RATIO_SLIDER_MAX; // (21.5)

// Low resolution defaults
const int LOW_SUR_DEV = 40;
const int LOW_NOR_DEV = 3000; // (30 degrees)
const int LOW_MAX_EDGE_LEN = MAX_EDGE_LENGTH_SLIDER_MAX; // (100.0)
const int LOW_ASPECT_RATIO = ASPECT_RATIO_SLIDER_MAX; // (21.5)

Key Points to Remember

• Maximum Edge Length and Aspect Ratio have default values of 100.0 and 21.5, respectively, across all resolutions (Low, Medium, and High).
• The Surface Deviation, Normal Deviation, MaxEdgeLength, and Aspect Ratio values are expected as integers in the API but are internally processed as doubles by dividing the integer values by 100.0.
• If input values exceed the specified range, the translator will default to the maximum allowed values.

By understanding how the Inventor API handles STL export settings, developers can more accurately configure and automate their workflows, ensuring that the exported STL files meet the desired quality requirements.

Repositioning Detail View ID Tag in Autodesk Inventor 2026 API

by Chandra shekar Gopal,

When working in Autodesk Inventor, keeping your drawings clean and readable is essential. A common challenge faced by users is repositioning the detail view ID tag—the identifier that marks a detail or section view. While moving a view label is straightforward, adjusting the position of the ID tag using the Inventor API has traditionally been far more complex. This blog explores the current limitations and a practical VBA workaround, and highlights a major improvement coming in Inventor 2026.

Understanding the Challenge

The Inventor API currently allows you to manipulate the fence (the circular or rectangular boundary around a detail view), including its shape and size. However, repositioning the ID tag that labels the view is not directly supported.

Some users attempt to work around this by deleting and recreating the detail view, which causes the reference to reappear next to the fence—but notably, without a leader. Unfortunately, the API doesn’t yet support adding a leader to restore that visual connection.

What’s Coming in Inventor 2026

There’s good news on the horizon. The Inventor 2026 release introduces a new API object: DrawingViewAnnotation. This enhancement includes the TextPosition property, which allows developers to programmatically move the ID tag of a drawing view—something that was previously unsupported.

The beta version of Inventor 2026 is already available, and we encourage developers and power users to begin testing these new capabilities.

Sample VBA Code to Reposition the ID Tag

To help you get started, here's a simple VBA script that demonstrates how to move the annotation text of a detail or section view using the new functionality:

Sub MoveViewAnnotationTextPositionSample()

    Dim oDoc As DrawingDocument
    Set oDoc = ThisApplication.ActiveDocument

    Dim oView As DrawingView
    Dim oTemp As DrawingView

    For Each oTemp In oDoc.ActiveSheet.DrawingViews
        If oTemp.ViewType = kDetailDrawingViewType Or oTemp.ViewType = kSectionDrawingViewType Then

            Set oView = oTemp

            Dim oViewAnnotation As DrawingViewAnnotation
            Set oViewAnnotation = oView.ViewAnnotation

            ' Move the annotation text
            Dim oPt As Point2d
            Set oPt = oViewAnnotation.TextPosition

            oPt.X = oPt.X + 2
            oPt.Y = oPt.Y + 3

            oViewAnnotation.TextPosition = oPt
            oDoc.Update

        End If
    Next

End Sub

Visual Example

Before
The view ID tag is misaligned or overlapping other elements.

After
The tag is repositioned cleanly within the drawing border.

Conclusion

While current versions of Autodesk Inventor have limitations in handling detail view ID tags via the API, the Inventor 2026 update is a game changer. With the new DrawingViewAnnotation object, developers will gain the long-awaited ability to programmatically reposition ID tags—improving drawing clarity and maintaining compliance with drafting standards.

Until then, the provided VBA workaround can help you manage your annotations more effectively and keep your documentation professional and clean.

iLogic to insert an image into Drawing Sketch by Sketched Symbols

by Chandra shekar Gopal,

Question:
How can I insert an image into the drawing sketch of the active sheet within a drawing document using iLogic code?

Answer:
In Autodesk Inventor, after creating a drawing sketch—whether via the user interface or API—the option to insert an image directly into the sketch is disabled (grayed out), as shown below. This means that inserting an image directly into a drawing sketch is not supported.

To work around this limitation, you can insert images into drawings by leveraging Sketched Symbols. Sketched Symbols allow you to embed images within a symbol that can then be placed on a drawing sheet.
For more details on creating Sketched Symbols, please refer to the comprehensive blog post here:

https://adndevblog.typepad.com/manufacturing/2012/08/creating-sketched-symbols.html 

---

Sample iLogic Code to Insert an Image Using Sketched Symbols

The following iLogic code demonstrates how to insert an image into the drawing sketch of the active sheet by creating and using a Sketched Symbol:

Dim oDwg As DrawingDocument
oDwg = ThisApplication.ActiveDocument

Dim oTG As TransientGeometry
oTG = ThisApplication.TransientGeometry

' Create a new Sketched Symbol definition
Dim oSSD As SketchedSymbolDefinition
oSSD = oDwg.SketchedSymbolDefinitions.Add("mySymbol")

' Open the sketch in edit mode
Dim oRes As DrawingSketch
Call oSSD.Edit(oRes)

' Add the image to the sketch at point (0, 4)
Call oRes.SketchImages.Add("C:\Temp\sample.png", oTG.CreatePoint2d(0, 4))

' Exit edit mode and save changes
oSSD.ExitEdit(True)

' Insert the sketched symbol onto the active sheet at point (10, 10)
Call oDwg.ActiveSheet.SketchedSymbols.Add("mySymbol", oTG.CreatePoint2d(10, 10))

By following this approach, you can effectively embed images into your drawing documents using iLogic, overcoming the limitation of direct image insertion into drawing sketches.

If you have any questions or need further assistance, feel free to leave a comment or reach out.

Autodesk Desktop API Update: .NET Core Migration in Inventor

by Chandra shekar Gopal,

On January 30th, 2024, Autodesk hosted a webinar on moving to .NET core covering Autodesk's flagship products like Inventor, AutoCAD, and Revit.

Please find the same webinar recordings in the YouTube link.

https://youtu.be/RyHx5-CqKZM?si=AyBIjZMvoleAjjNT

Webinar Presentation

-    Presentation slides

Inventor .NET migration guide.

-    Guide to migrate .Net Framework Inventor addins into .Net 8 Core.mp4

-    Guide to migrate .Net Framework Inventor addins into .Net 8 Core.pdf

Sorting “invalid arguments” error in C# add in code for generating 3D PDF in Inventor

The VB.NET add-in for 3D PDF generation works well and directly without issues. However, the C# API code throws an invalid arguments error at the Publish() method. This is because the code uses late binding.  This blog contains steps on how to resolve this error

Step 1:
As mentioned in this blog (here) set the Embed Interop Type to False under the Inventor Interop Assembly reference

Step 2:
Add the Microsoft.CSharp reference to your project then import the namespace in the code

 

Step 3:
Declare the PDF converter 3D ApplicationAddin Variable as dynamic as seen below
dynamic oPDFConvertor3D ;
oPDFConvertor3D = oPDFAddIn.Automation;

Step 4:
The Publish() method takes two arguments, the first is of type Inventor document and the second is of Inventor NameValueMap type. Declare the variable of the type document as dynamic before parsing it to the method.

See the sample code below

dynamic oDocument;
oDocument = m_inventorApplication.ActiveDocument;

These steps should be able to resolve the error.

- Fidel

Porting guide from Level of Details to Model states.

by Chandra shekar Gopal,

Introduction to Model States

Model States were introduced in Inventor 2022. While product documentation covers the basics well, our ADN team has offered extensive support for developers transitioning to this feature. With Inventor 2023 now released, it’s a good time to review code migration requirements and discuss some known issues.

Official Documentation

These links, provided for Inventor 2023, also apply to Inventor 2022:

• Introducing Model States (What's New in 2022)
• About Model States

Key Observations

“Design Options” and “varying configurations” are important facets of Model States. Compared to the older Level of Detail (LOD) feature, Model States offer improved flexibility—but can also present migration challenges.

Developer Impact

Inventor developers have generally experienced smooth transitions between versions. However, Model States represent the most disruptive change to date. We'd love to hear how we can better support you—please leave your thoughts in the comments below.

Conversion of Level of Detail into Model State

Understanding how LODs convert to Model States is crucial. See the documentation here:

About Level of Detail Migration

API Aspects

Autodesk has updated the API documentation to help developers. Reference:

Working with Model States

Legacy API: Accessing LOD in Inventor 2021

Sub GetLods()
    Dim sFileName As String
    sFileName = "C:\Temp\Assembly1.iam"

    Dim oDoc As AssemblyDocument
    Set oDoc = ThisApplication.Documents.Open(sFileName)

    Dim oAssemblyCompDef As AssemblyComponentDefinition
    Set oAssemblyCompDef = oDoc.ComponentDefinition

    Dim oLODs As LevelOfDetailRepresentations
    Set oLODs = oAssemblyCompDef.RepresentationsManager.LevelOfDetailRepresentations

    Dim oLOD As LevelOfDetailRepresentation
    For Each oLOD In oLODs
        Debug.Print oLOD.Name
    Next

    oDoc.Close True
End Sub

Different Types of Documents with Respect to Model State

Parts or assemblies fall into one of three categories:

• Plain Document
• Model State Document
• iComponent (iPart/iAssembly) Document

Document Type Boolean Table

Type	IsModelState Factory	IsModelState Member	IsiPartFactory	IsiPartMember	IsiAssembly Factory	IsiAssembly Member
Plain Document
Model State Factory	True
Model State Member		True
iPart Factory			True
iPart Member				True
iAssembly Factory					True
iAssembly Member						True

Factory vs Member Documents

Model State Factory Document

• Fully editable
• Drives all variations
• Includes UI frame
• Not stored on disk

Model State Member Document

• Represents a variation
• Non-modifiable (if factory exists)
• No full UI
• Multiple members per file

Accessing iProperties via Apprentice Server API

In Inventor 2022, ApprenticeServerDocument.PropertySets returns only active model state properties. Use FilePropertySets (added in Inventor 2022.1) for editable iProperties.

Behavioral Notes

IsModifiable in Inventor 2022

When a Model State is added, IsModifiable = True, blocking property edits via Apprentice. Deleting the model state reverts this.

DocumentDescriptor Behavior

In Inventor 2022, suppressed occurrences were excluded from ReferencedDocumentDescriptors.Count. This is resolved in Inventor 2023.

Checking Dirty States of Model State Members

Dim doc As AssemblyDocument
Set doc = ThisApplication.ActiveDocument

Dim oMs As ModelState
For Each oMs In doc.ComponentDefinition.ModelStates
    If oMs.ModelStateType = kSubstituteModelStateType Then
        Dim oMsDoc As AssemblyDocument
        Set oMsDoc = oMs.Document
        If Not oMsDoc Is Nothing Then
            Debug.Print oMs.Document.Dirty
        End If
    End If
Next

Alternative for Substitute Model State

Dim oSub As AssemblyDocument
Set oSub = ThisApplication.Documents.ItemByName("D:\Temp\Assembly1.iam<Substitute1>")
Debug.Print oSub.Dirty

Substitute LOD iProperties in Pre-2022 Files

In older files, substitute LODs become substitute model states. iProperty access via API was fixed in Inventor 2022.3 and 2023:

Sub GetPartNumber()
    Dim doc As Document
    Set doc = ThisApplication.ActiveDocument
    Debug.Print doc.FullDocumentName

    Dim propSet As PropertySet
    Set propSet = doc.PropertySets.Item("{32853F0F-3444-11D1-9E93-0060B03C1CA6}")

    Dim prop As Property
    Set prop = propSet.Item("Part Number")
    Debug.Print "PartNumber=" & prop.Value
End Sub