Manufacturing DevBlog

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 and even though the product documentation has good details, our ADN team has provided much support around the issues to move to the model states feature. Now that Inventor 2023 has come out last week, it’s a good time to review the porting requirements in your code for Model States and discuss some of the known issues.

Let’s start by reviewing the documentation. These links are provided for the 2023 product, but also present in 2022:

Feature Aspects:
Introducing Model States (What's New in 2022)
About Model States

Adding my own perspective to the “introduction” topic, I would also like to add that “Design Options” and “varying configurations” are important aspects of this new Models States feature.

As you can see, there is already detailed information in the product documentation. When comparing this to the old Level of details representation (LOD) feature, there is much improvement to how you can work with different representations of the model, but this can also present some migration problems. When discussing this internally, we realized that Inventor developers have actually had a fairly easy migration path in the past (when compared to AutoCAD or 3ds Max for example).  The Model States feature seems to be the most disruptive so far. We would be happy to hear your ideas about how we can better support you in future when such major features are coming in Inventor, Please feel free to leave comments below.

Conversion of Level of Detail into model state

One topic that you will need to fully understand to handle model migration is how the LOD is converted to Model States. This is explained in the docs here: About Level of Detail Migration

API aspects

The API documentation as also updated to help support developers. See here: Working with Model States. In the next sections, I will discuss application specific issues.

 

The Legacy way of accessing Level of Detail Representation (LOD) API in Inventor 2021

Let’s start with looking at how to access the legacy Level of detail representation items, they are accessible through ReprenstationManager object of AssemblyComponentDefinition

 

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

 

    ' Get Level of Detail Representations collection object.

    Dim oLODs As LevelOfDetailRepresentations

    Set oLODs = oAssemblyCompDef.RepresentationsManager.LevelOfDetailRepresentations

 

    ' Get all Level of Detail Representation names from Level of Detail Representations object.

    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  

Part or Assembly can be categorized as three types, 

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

When a new part or assembly is created, usually we can only see Master model state there. At this moment, such part or assembly is called a Plain Document. Plain document is not model state document and not iComponent document. A master model state document is basically a document without any model states in it. The reason why we design this way is providing user a visible way to create Model State. 

If user starts to create at least one additional Model State (end up with Master and another new created Model State), this document becomes Model State document. The user cannot create any iComponent there.  

User cannot create any Model State inside it. iComponent document also has two types (factory and member). 

We plan this way is truly connected with how clients utilize Model State and iComponent to tackle issues. They are totally unrelated

If you look from bigger picture, plain document is just like legacy normal document. Model State and iComponent both are table driven document. When a document becomes table driven document, these Booleans start

After understanding the design, let me list these Boolean in a table (together with some legacy booleans). The empty cells means False. 

	IsModelStateFactory	IsModelStateMember	IsiPartFactory	IsiPartMember	IsiAssemblyFactory	IsiAssemblyMember
Plain Document
Model State Factory	True
Model State Member		True
iPart Factory			True
iPart Member				True
iAssembly Factory					True
iAssembly Member						True

 

Member document v/s Factory document

Essentially, Factory document is the document for user to create model states or design modeling recipe (feature, component). You can think of it as (in general) all edits user do need be Factory document environment. For example, user creates 3 model states in Factory Document (ms1, ms2, ms3).

Member document represents one result document from one of model states (e.g., ms1). This is only elaborated when placing ms1 into other assembly, or derived into another part, or place into drawing view. It is for consumption purpose. This document usually cannot be modified. Member document update is always driven by Factory Document. Please note, these documents are only elaborated on demand. If we do not consume, there might be no member document there.   

Model State Factory Document

• Full editing document with Model States
• Drive variations in members
• Presented with UI Frame
• Floating document, no storage on disk
• Generated from one of member document storage on the fly

Model State Member Document

• Represent Model State Member
• Non-modifiable when Factory document is available
• Usually no UI Frame except in-place-edit
• Each physical file might have multiple member

 

Facts about accessing the iProperties of Model State via Apprentice Server 2022 API

The ApprenticeServerDocument.PropertySets currently just return the iProperty of the active model state, and the model state level iProperty is regarded as the model data so Apprentice can’t edit at present.  

A new API ApprenticeServerDocument.FilePropertySets is exposed in Inventor 2022.1 release, and this FilePropertySets is File level iProperty, and it will return the same property values as the iProperty of master model state, and you can also change the property values in FilePropertySet.  If you want to edit the iProperty of a custom model state, it is recommended to use Inventor Server or Inventor instead.

 

Behavior of IsModifiable value after adding custom model state in Inventor 2022

Any Inventor 2022 part with an added model state causes IsModifiable value to be true and prevents any updates of iproperties with apprentice server. Removing the model state then allows updates as IsModifiable is then set to false. When there are two parts (one with model state and one without) can be used to demonstrate the issue. Open a part and try to update a property, it works on the part without a model state but fails on the same part with model state added.

The legacy ApprenticeServerDocument.PropertySets does not work in ApprenticeServer anymore when there is custom model state, and in Inventor 2022.1 we introduced a new ApprenticeServerDocument.FilePropertySets instead, so you should make use of the new API to update the file level iProperties. 

 

Behavior of DocumentDescriptor object with model state in Inventor 2022

In a situation in Inventor 2022, a custom model state is added to an assembly. In that custom model state, suppress the few occurrence and activate the custom model state. On retrieving the count of ReferencedDocumentDescriptor using below VBA code, it gives wrong number count (lesser than the actual count). Few suppressed occurrences were not included in the count of ReferencedDocumentDescriptor.

ThisApplication.ActiveDocument.ReferencedDocumentDescriptors.Count

This behavior has been rectified and fixed in Inventor 2023. Open the same assembly and activate custom model state (few occurrences were suppressed). On counting the number of DocumentDescriptor using same above VBA code, it gives exact number of DocumentDescriptor which are participated in an assembly. Even though, few occurrences are suppressed in custom model state of an assembly.

 

Checking Dirty states of Model state member Document

As we know that each model state (including master/model state/substitute) could have its own member document, and there could also have different dirty states. Normally we cannot use the dirty state of master document to represent all the member docs. 
 
So one work around for the developers could be check the dirty state for each model state or only substitute without activating them: 

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 

Another solution could be getting the substitute document only and checking its dirty state if the developer only cares about the substitute: 
 
Dim oSub As AssemblyDocument 
 
Set oSub = ThisApplication.Documents.ItemByName("D: \Temp\Assembly1.iam<Substitute1>") 
 
Debug.Print oSub.Dirty

 

Checking iProperty value for substitute LOD saved which is saved in lower than Inventor 2022 version.

In a scenario, an assembly which is saved Inventor version lower than 2022. It means that Level of Detail (LOD) is available in assembly files instead of model state. When the same assembly is opened in Inventor 2022, substitute LOD becomes substitute model state. In doing this upgrade, iProperty value (Part Number) of assembly after activating substitute model state is unable to retrieve through Inventor API using VBA code.

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

This behavior has been addressed in Inventor 2022.3 and 2023. Now, iProperty value for substitute LOD which is saved in lower than Inventor 2022 version can be retrieved through Inventor API.

Using Entitlement API for Inventor 2023

By Sajith Subramanian

As you may be already aware, If you have an app on the Autodesk App Store, then you might want to check if the user actually paid for and downloaded your app from the store, or just copied it from someone else's computer. This is what the Entitlement API can help you with.

Inventor 2023 API has introduced 3 new properties to help with checking the Entitlement:

• LoggedIn  - Read-only property that returns whether the user has logged in the online services or not.
• LoginUserId - Read-only property that returns the login user Id(this is the same as the A360 oxygen Id). This returns an empty string if user has not logged in.
• LoginUserName - Read-only property that returns the online services login user name. This returns an empty string if user has not logged in.

The Entitlement API is a simple RESTful API where you just need to send an HTTP GET request to the App Store server.

Below is the sample code that demonstrates this usage:

m_inventorApplication = addInSiteObject.Application;
   if (m_inventorApplication.LoggedIn) // check if user has logged in
      {

      //string username = m_inventorApplication.LoginUserName; //returns the logged in username
         string userId = m_inventorApplication.LoginUserId; // returns the logged in userID
         string appId = "<Enter Your APP ID here>";
                    
         string urlParameters = String.Format("?userid={0}&appid={1}", userId, appId);
         string responseBody = await httpClient.GetStringAsync(urlParameters);
         EntitlementResponse entitlementResponse = JsonSerializer.Deserialize<EntitlementResponse>(responseBody);

        if (entitlementResponse.IsValid == true)
            {
              // user validated... execute rest of the code…
             }

         }

You can find the full source code here:

https://github.com/sajith-subramanian/EntitlementAPI-Inventor

Working with PropertySets and Model States

By Sajith Subramanian

If you wish to change a Property's value on a document having Model States, the workflow via API is the similar to the Inventor UI:

• Activate the required Model State using ModelState.Activate.
• Set the MemberEditScope to either kEditActiveMember or kEditAllMembers based on whether the updated value would be applied only to the active model state or all members.
• Get the property from Factory document (and not the Model State document), and change its value.
• To confirm whether the required Property has been correctly updated, activate the respective Model State and query the property from the Factory Document.

Here is a sample VBA code that exhibits a similar workflow:

Sub ModelStateProps()

Dim oPartDoc  As PartDocument
Set oPartDoc = ThisDocument

Dim oCompDef As PartComponentDefinition
Set oCompDef = oPartDoc.ComponentDefinition

Dim oModelStates As ModelStates
Set oModelStates = oCompDef.ModelStates

‘Fetch the required Model State from the collection

Dim oModelState As ModelState
Set oModelState = oCompDef.ModelStates("Model State 1")

'Activate the model state
oModelState.Activate

' Get the design tracking property set for our model state.
Dim oSummaryInfo As Inventor.PropertySet
Set oSummaryInfo = oPartDoc.PropertySets.Item("Inventor Summary Information")

' Get the Comments property.
Dim oCommentsProperty As Property
Set oCommentsProperty = oSummaryInfo.Item("Comments")

' Set the Member Edit Scope
oModelStates.MemberEditScope = kEditActiveMember  'kEditAllMembers for all members

'Set the value
oCommentsProperty.Value = "Updating comments via API!"

End Sub

A couple of things to remember:

• It is recommended to edit in the Factory Document context and activate the Model State you wish to edit.
• It is not recommended to change the Model State Member Document directly. Also, the Member Document may not exist, if not already generated. Hence, your code would return a ‘Null’ in such cases, as shown below.

Using a Named User License with a Custom Web Application

By Sajith Subramanian

Users having a Named User license and working with a custom web application, can now login into Vault with their Named User license, with the existing Standard / Windows authentication.

With the Vault 2021.2 update onwards, the LogInWithUserLicense() method was added to support this workflow.

The sample code syntax for this method would be similar to:

VDF.Vault.Results.LoginResult results = VDF.Vault.Library.ConnectionManager.LogInWithUserLicense(
                 tbServerName.Text, tbVaultName.Text, tbUserName.Text, tbPassword.Text, Token, VDF.Vault.Currency.Connections.AuthenticationFlags.Standard, null);

m_conn = results.Connection;

The above method takes in an additional input parameter "Token". You can refer to the Forge documentation on how to generate this token:
https://forge.autodesk.com/en/docs/oauth/v2/tutorials/get-3-legged-token/

The Vault SDK also contains a ready to compile sample that demonstrates this workflow. On a default installation of Vault, you can find it here:
C:\Program Files\Autodesk\Autodesk Vault 2022 SDK\VS19\CSharp\WebAppUserLicense
Do take a look at the included Readme.txt file that contains additional details to help build and run this sample.

Check if the File links of an Item are up-to-date

By Sajith Subramanian

If you wish to check if the file links of an item are up-to-date, using the API, then you can make use of the ItemFileLinkState property for that particular Item. So for e.g:

try
{    
  Item item = connection.WebServiceManager.ItemService.GetLatestItemByItemNumber("10001");   

  PropDef[] propDefs =
    connection.WebServiceManager.PropertyService.GetPropertyDefinitionsByEntityClassId("ITEM");  

  PropDef propdef =
  propDefs.Where(s => s.SysName == VDF.Vault.Currency.Properties.PropertyDefinitionIds.
                                                             Server.ItemFileLinkState).First();  

  PropInst prop = 
    connection.WebServiceManager.PropertyService.GetProperties("ITEM", 
                                        new long[] { item.Id }, new long[] { def.Id }).First();     

  var value = prop.Val;
}

This would return 3 possible values - 0, 10 and 20, which basically means: 0 – “Out of Date “; 10 – “Current”; 20 - "No links".

Retire Registry-based Add-ins in Inventor 2022

by Chandra shekar Gopal,

Before Inventor 2010, add-ins are loaded into Inventor by running registry mechanism in a command prompt. It was complex procedure. So, the registry free add-in mechanism was introduced into Inventor 2010.

Now in Inventor 2022, the registry based add-ins will not be listed in the Inventor Add-Ins Manager dialog as default. So, it is recommended to convert registry based add-ins into registry free add-ins. The guidelines to convert registered add-ins into registry free add-ins is explained in the below article.

https://help.autodesk.com/view/INVNTOR/2021/ENU/?guid=GUID-CFFA5CC6-38E6-4ACD-A2BC-8B8732727996

In case, registered add-ins are can't convert.  The registered add-ins in current version can be enabled by modifying below registry key.

HKEY_CURRENT_USER\Software\Autodesk\Inventor\RegistryVersion26.0\System\Preferences
LoadRegisterBasedAddins = dword:00000001

 

 

Power(Shell)ing the Inventor API!

By Sajith Subramanian

If you are more comfortable using PowerShell and have an Inventor API workflow that you want to quickly test, you can just combine both!

To help demonstrate this, below is a Inventor API sample in PowerShell that exports a drawing file as PDF.

Once you have your Windows PowerShell Integrated Scripting Environment (ISE) up, the first line of code would be to add the Inventor reference DLL as below:

Add-Type -Path ("C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Autodesk.Inventor.Interop\v4.0_25.0.0.0__d84147f8b4276564\Autodesk.Inventor.Interop.dll")

The next step would be to create an instance of Inventor (or get an existing instance if it is already open). To do so, you can add the below lines:

try
{
$m_inventorApp = [Runtime.Interopservices.Marshal]::GetActiveObject('Inventor.Application')
$m_quitInventor = $false
echo 'Getting existing instance...'
}
catch
{
     echo 'Creating new instance...'
     $inventorAppType = [System.Type]::GetTypeFromProgID("Inventor.Application");
     $m_inventorApp = [System.Activator]::CreateInstance($inventorAppType) 
     $m_quitInventor = $true
}

Now, we open our input drawing document with the “Open as Visible” flag set to False, and use this document object as input to the PublishPdf function.

$document = $m_inventorApp.Documents.Open("C:\TEMP\Hairdryer.idw", $false)
PublishPdf($document)

Now, in our PublishPdf function we add the below lines:

function PublishPdf {
   param ($doc)
   $PDFAddIn = $m_inventorApp.ApplicationAddIns.ItemById("{0AC6FD96-2F4D-42CE-8BE0-8AEA580399E4}")
   $oContext = $m_inventorApp.TransientObjects.CreateTranslationContext() 
   $oContext.Type = [Inventor.IOMechanismEnum]::kFileBrowseIOMechanism
   $oOptions = $m_inventorApp.TransientObjects.CreateNameValueMap()
   $oDataMedium = $m_inventorApp.TransientObjects.CreateDataMedium()
   If ($PDFAddIn.HasSaveCopyAsOptions($doc, $oContext, $oOptions)) 
    {
     
       $oOptions.Value("All_Color_AS_Black") = 0
    }
    
   $oDataMedium.FileName = "c:\temp\test.pdf"
       
   $PDFAddIn.SaveCopyAs($doc, $oContext, $oOptions, $oDataMedium)
}

And finally, close the created Inventor instance:

if ($m_inventorApp -ne $null -and $m_quitInventor -eq $true)
{
 $m_inventorApp.Quit()
 echo 'Quitting Inventor...'
} 

In the above example, while I have hard-coded the input file path, you can also choose to pass this as an input in a command line argument.

Level Of Details in next Inventor release

As Garin mentioned in this post, one of the new features the team has been working on is Model States.

This might have an effect on some of the Level Of Details related functions, events, and properties in the API.

If you are using any of those, the best thing to do is join the beta program where you can find more details about this functionality and can also use pre-release versions (alphas and betas) of Inventor to test your add-in.

Using Microsoft Edge WebView2 in a DetailPaneTab

By Sajith Subramanian

Previously, in order to have a Chromium based browser control, you probably would have used CefSharp. Now there is an alternative which is also Chromium based, i.e. the WebView2.

One of the quicker and easier ways to test this, would be using the HelloWorld sample that comes along with the Vault SDK.

The first step in our HelloWorld sample would be to add the WebView2 SDK. To do so, navigate to Tools –> NuGet Package Manager –> Manage NuGet Packages for Solution, and install the WebView2 as shown below.

Next, open the UserControl file as Designer and add the WebView2 control as shown below:

For a complete step by step guide on using WebView2 with Windows forms, do take a look at the below article:

https://docs.microsoft.com/en-us/microsoft-edge/webview2/gettingstarted/winforms

Now, in our Command Extension class, i.e. the HelloWorldCommandExtension.cs in the HelloWorld sample, add the below lines of code in the DetailTabs() function.

public IEnumerable<DetailPaneTab> DetailTabs()
   {
     // Create a DetailPaneTab list to return from method
     List<DetailPaneTab> fileTabs = new List<DetailPaneTab>();
      // Create Selection Info tab for Files
       DetailPaneTab filePropertyTab = new DetailPaneTab("File.Tab.browsertab",
                                                   "Browser Tab",
                                                   SelectionTypeId.File,
                                                   typeof(BrowserControl)); //type of our UserControl
   //The propertyTab_SelectionChanged is called whenever our tab is active and the selection    
     //changes in the main grid 

    filePropertyTab.SelectionChanged += propertyTab_SelectionChanged;
    fileTabs.Add(filePropertyTab);

Next add the below code in the Selection Changed event of our custom tab.

void propertyTab_SelectionChanged(object sender, SelectionChangedEventArgs e)
        {
            try
            {
                // The event args has our custom tab object.  We need to cast it to our type.
                BrowserControl tabControl = e.Context.UserControl as BrowserControl;
            }
            catch (Exception ex)
            {
              // If something goes wrong, we don't want the exception to bubble up to Vault Explorer.
                MessageBox.Show("Error: " + ex.Message);
            }
        }

Lastly, to get this up and running, you would need the WebView2 runtime. You can download it here.

You should now have the browser control show up in your custom tab!

Fusion 360: JavaScript API is being fully retired

By Sajith Subramanian

The end of support for the JavaScript API was announced a couple of years ago.

However, so far any scripts or add-ins that were written using the JavaScript API have continued to run.

Please note that this is set to change, and as of the December release of Fusion 360 they will no longer run at all.

Any script or add-in using the JavaScript API will need to be migrated to either Python or C++.

Please find the official announcement here:

Notice: JavaScript API is being fully retired