Mod the Machine

Debug new Inventor 2025 add-in

When creating a new add-in you can take advantage of the Visual Studio 2022 templates that are installed as part of the developertools.msi installer found in C:\Users\Public\Documents\Autodesk\Inventor 2025\SDK
More info on it: https://help.autodesk.com/view/INVNTOR/2025/ENU/?guid=GUID-52422162-1784-4E8F-B495-CDB7BE9987AB 

You can simply create a folder for your app under C:\ProgramData\Autodesk\Inventor Addins\

and set the Base output path of your project to this in the Project Properties panel so that both the *.addin file and the dll will end up at the right location, i.e. where Inventor can find them.

One more thing to do is set the Copy to Output Directory property of the *.addin file to Copy if newer so it does get copied into the folder we created.

Usually, when you want to debug your add-in, you want Visual Studio to start up Inventor which will then load your add-in.
In the case of .NET Framework add-ins (like the one for Inventor 2024) that was an option using Start external program:

In the case of an Inventor 2025 .NET 8.0 add-in that option is not exposed directly in the Visual Studio UI. What you can do is modify e.g. the Command line arguments of the Launch Profile which will then generate a launchSettings.json file under the Properties folder - just make sure Show All Files option is enabled in the Solution Explorer so that you can see the file.  

Now you can just open the launchSettings.json file and modify the content of the profile so that it's using the highlighted parts:

{
  "profiles": {
    "InventorAddIn2025": {
      "commandName": "Executable",
      "executablePath": "C:\\Program Files\\Autodesk\\Inventor 2025\\Bin\\Inventor.exe"
    }
  }
}

Now when you click the Debug button Inventor will start up

A developer just told me that there is another way to run Inventor when debugging - you just have to create a new Executable profile that allows you to specify the path of an Executable (I also renamed it to Start Inventor to make it clear what it does)

As usual, the first time Inventor encounters your add-in it will block it (unless it's been signed) and warn you about it, so you just have to go to the Add-In Manager, unblock it and load it

If you placed a break point inside the Activate method, that should be hit 🥳

A Problem with Attribute Helper and a Fix

A partner notified me about a problem he had found with my Attribute Helper add-in that I wasn’t aware of. He told me that if you have the new “Interactive Tutorial” and “Attribute Helper” add-ins both loaded, then Inventor will crash when you shut it down with the dialog below.

 

As I said, I wasn’t aware of the problem but had a good idea of the cause. I wasn’t following my own advice from this post almost a year ago.  I made the changes recommended there so that my Deactivate method of the add-in went from this:

Public Sub Deactivate() Implements Inventor.ApplicationAddInServer.Deactivate
    ' Release objects.
    Marshal.FinalReleaseComObject(g_inventorApplication)
    g_inventorApplication = Nothing

    If Not m_attributeButtonDef Is Nothing Then
        Marshal.FinalReleaseComObject(m_attributeButtonDef)
    End If

    If Not m_UIEvents Is Nothing Then
        Marshal.FinalReleaseComObject(m_UIEvents)
        m_UIEvents = Nothing
    End If

    System.GC.WaitForPendingFinalizers()
    System.GC.Collect()
End Sub

To this:

Public Sub Deactivate() Implements Inventor.ApplicationAddInServer.Deactivate
    ' Release objects.
    m_attributeButtonDef = Nothing
    m_UIEvents = Nothing
End Sub

 

With that change, the crash went away. I hadn’t published a new version of the “Attribute Helper” add-in for a couple of years so I’ve made this change and created a new installer.  You can get the latest version of “Attribute Helper” here.  After installing make sure that you’re running the latest version by checking that the version is 2.6, as shown below.

And if attributes are new to you, you can learn more about what they are here.  The source code for the add-in is also available on GitHub.

-Brian

Fusion Add-In with .NET (C++ & CLR)

I've written about using MFC from a C++ Fusion add-in. You could also use .NET from your add-in, and it's even simpler to set up.

1) Create a C++ add-in inside the "Scripts and Add-Ins" Fusion dialog:

I'm leaving "Run on Startup" option above unchecked, because it would not be a good idea to pop up a modal dialog while Fusion is starting up. That would halt the startup process.

2) Open it for edit:

3) Add "Common Language Runtime Support" in your C++ project's Properties dialog

4) Place the Fusion related code inside a #pragma unmanaged /#pragma managed block

5) Add a "Windows Form" through "PROJECT" >> "Add New Item..."

Note: You can add any of the .NET Form controls to it as in case of a C# or VB.NET project. I've just added a list box for testing and filled it with items.

6) Create a function to show this dialog

a) In "MyForm.h" declare showDialog()

b) In "MyForm.cpp" implement the function

7) Now we can call it from the startup function called run()

a) Add #include "MyForm.h" to the top of "CustomNetUi.cpp"

b) Call showDialog() from run()

extern "C" XI_EXPORT bool run(const char* context)
{
  app = Application::get();
  if (!app)
    return false;

  ui = app->userInterface();
  if (!ui)
    return false;

  showDialog();

  return true;
}

8) Test the app by running it from the "Scripts and Add-Ins" Fusion dialog:

The sample project can be found here:
https://github.com/AutodeskFusion360/NativeUI

-Adam

Fusion Add-In with MFC

It is possible to use MFC functionality inside your Fusion add-in on Windows.
First I tried going down the path of creating a C++ add-in inside the "Scripts and Add-Ins" Fusion dialog and then add MFC support to the created Visual Studio C++ project. However, that proved quite difficult and I just gave up and went the other way: created an MFC DLL project and turned it into a Fusion add-in. That was much simpler. 

1) Create an MFC DLL project

2) Add a Dialog resource to it

Open CustomMfcUi.rc, right-click and choose "Add Resource..."

... then select "Dialog" and click "New"

3) Double-click the "OK" button of the newly added Dialog so that the "MFC Add Class Wizard" dialog will pop up: 

Fill it in and click "Finish"

4) Rename IDD_DIALOG1 to IDD_MYDIALOG just to keep things tidy

You can use the "Find and Replace" dialog of Visual Studio for that:

There should be 4 instances replaced at the end:

5) Add a function to show our dialog

a) Inside CustomMfcUi.cpp add this code:

void showDialog()
{  
  // Always call this macro first thing in any function that
  // will use MFC functionality
  AFX_MANAGE_STATE(AfxGetStaticModuleState());

  CMyDialog myDialog;
  myDialog.DoModal();
};

b) Inside CustomMfcUi.h add this code at the top:

#include "MyDialog.h"

void showDialog();

6) Add Fusion functionality 

Add a new C++ file to the project called FusionCode.cpp 

Fill it with this code:

#include "stdafx.h"

#include <Core/CoreAll.h>
#include <Fusion/FusionAll.h>

// XI_WIN is a macro added by Fusion headers
// to show if the project is a Windows project
#ifdef XI_WIN
  #include "CustomMfcUi.h"
#endif

using namespace adsk::core;
using namespace adsk::fusion;

Ptr<Application> app;
Ptr<UserInterface> ui;

extern "C" XI_EXPORT bool run(const char* context)
{
  app = Application::get();
  if (!app)
    return false;

  ui = app->userInterface();
  if (!ui)
    return false;

  showDialog();

  return true;
}

extern "C" XI_EXPORT bool stop(const char* context)
{
  if (ui)
  {
    ui->messageBox("in stop");
    ui = nullptr;
  }

  return true;
}

7) Make the project compile as 64 bit since Fusion 360 is 64 bit too

Inside the "Configuration Manager" dialog, under "Active solution platform" select "<New...>"

... and add the "x64" platform

8) Add references to Fusion headers and libraries so that our project will compile

a) Inside the project settings, under "C/C++" >> "Additional Include Directories" add "$(APPDATA)/Autodesk/Autodesk Fusion 360/API/CPP/include" 

b) Under "Linker" >> "Additional Library Directories" add "$(APPDATA)/Autodesk/Autodesk Fusion 360/API/CPP/lib"

c) Under "Linker" >> "Additional Dependencies" add "core.lib;fusion.lib;"

9) Let Fusion find our project

a) Under "$(APPDATA)\Autodesk\Autodesk Fusion 360\API\AddIns" create a folder named the same as our dll "CustomMfcUi" 

Add to that folder a manifest file with the same name, i.e. "CustomMfcUi.manifest" and add the following content to it in any text editor:

{
"autodeskProduct":"Fusion360",
"type":"addin",
"author":"",
"description":{"":""},
"supportedOS":"windows",
"editEnabled":false,
"id":"38EE9339-591A-4F72-AFFF-7B20111CC10C",
"version":"1.0.0",
"runOnStartup":false
}

The "id" part in the above text needs to be unique. You could use e.g. Visual Studio's "Create GUID" dialog for that. Just remove the curly braces from the generated string

I'm setting the "runOnStartup" option above to false because it would not be a good idea to pop up a modal dialog while Fusion is starting up. That would halt the startup process.

b) Make our project output the created dll into the Add-In folder we just created. Inside the project settings under "General" >> "Output Directory" add the path of our folder "$(APPDATA)\Autodesk\Autodesk Fusion 360\API\AddIns\CustomMfcUi"   

10) Test it

Compile the project and inside the "Scripts and Add-Ins" dialog of Fusion, select our add-in and click "Run"

Our dialog should pop up

The sample project can be found here:
https://github.com/AutodeskFusion360/NativeUI

-Adam 

Add control to toolbar panel

It's worth downloading existing apps from the Fusion 360 exchange store even just to see if they already implement a certain functionality that you are interested in. In which case you can look at the source code (if it's a JavaScript or Python add-in) and see how things are done.

E.g. the ExactFlat add-in creates its own toolbar panel and promotes its single button control to that panel.

It's done using this part of the Python code:

# "toolbarControlPanel_" is the button control added to the panel 
toolbarControlPanel_.isPromoted = True
toolbarControlPanel_.isPromotedByDefault = True

isPromoted = True will make the control show up on the panel - just like when clicking the curved arrow (Add to toolbar) on a control in a panel menu:

But if the user clicks Reset Panel Customization on the given panel or Reset All Toolbar Customization anywhere on the toolbar then the button will disappear from the panel.   

isPromotedByDefault = True will make sure that the button stays on the panel even if the toolbar is reset using either of the above mentioned ways.

Add-In with event example to replace auto-run macros in 2014

Inventor 2014 no longer supports VBA auto-run macros. Here is an excerpt from the Inventor API help file:

Autodesk Inventor 2014 removes support for VBA auto-run macros that are embedded in Autodesk Inventor documents. The VBA macros are AutoOpen, AutoNew, AutoSave, AutoClose, and AutoEdit. They can severely impact Autodesk Inventor performance, and pose a possible security risk. The suggested alternative to auto macros is an add-in. Add-ins don't have the performance and security issues of auto macros and provide much better source control.

If you are using VBA auto-run Macros you will need to start using events to get the same functionality. In one case the AutoSave macro was being used to add the time and day to custom iProperties. This stopped working in Inventor 2014. To get the behavior back an Add-In with an OnSaveDocument event needed to be used. Here is the VB.NET (VS 2010) project that creates an Add-In that that can be used to replace the behavior of the AutoSave VBA macro.

Download AddIn_With_Saved_Event 

There are instructions for creating an Add-In in the API help file. 

.

Here is the event callback:

Private Sub m_ApplicationEvents_OnSaveDocument _

      (ByVal DocumentObject As Inventor._Document,

  ByVal BeforeOrAfter As Inventor.EventTimingEnum,

           ByVal Context As Inventor.NameValueMap,

  ByRef HandlingCode As Inventor.HandlingCodeEnum)

 

    If BeforeOrAfter = EventTimingEnum.kBefore Then

        Try

            'Ensure active document is a Drawing

            If m_inventorApplication.

                           ActiveDocumentType = _

       DocumentTypeEnum.kDrawingDocumentObject Then

 

                'Get the custom iProperties

                Dim oPropSet As PropertySet = _

m_inventorApplication.ActiveDocument.PropertySets _

          ("{D5CDD505-2E9C-101B-9397-08002B2CF9AE}")

 

                Dim bDateAdded As Boolean = False

                Dim bTimeAdded As Boolean = False

 

                Dim prop As Inventor.Property

                For Each prop In oPropSet

                    If prop.Name = "SysDate" Then

                        prop.Value = _

                     Format(Date.Now, "MMM-d-yy")

 

                        bDateAdded = True

                    End If

 

                    If prop.Name = "SysTime" Then

                        prop.Value = _

                  Format(Date.Now, "hh:mm:ss tt")

 

                        bTimeAdded = True

                    End If

                Next

 

                ' If the drawing does not have the

                ' SysDate custom property

                If bDateAdded = False Then

                    oPropSet.Add(Format(Date.Now, _

                            "MMM-d-yy"), "SysDate")

                End If

 

                ' If the drawing does not have the

                ' SysTime custom property

                If bTimeAdded = False Then

                    oPropSet.Add(Format(Date.Now, _

                         "hh:mm:ss tt"), "SysTime")

                End If

 

            End If ' if document is a drawing

        Catch ex As Exception

            MsgBox(ex.ToString())

 

        End Try

    End If 'if before save

 

End Sub

 

-Wayne

Migrate .Net Add-Ins to registry free

Inventor 2012 allows your Add-Ins to be loaded without them being registered as a COM component in the Windows registry. These Add-Ins are called “registry free Add-Ins”. I was sure happy when I could have my Add-In load without having to use the Windows registry. It really makes installing custom applications much  easier.  The Inventor 2012 Add-In wizard provided with the SDK uses a new template that generates a Registry Free Add-In. If you want to migrate your existing Add-Ins without re-creating them from scratch (using the new template) you can follow these five steps. Happy migration! 1. Remove COM Registration  Uncheck the Register for COM interop check box on the “Compile” tab of the Application Properties dialog, as shown below:

Note: In Visual Studio Express Edition this setting does not exist.

Remove any code associated with registering the add-in in the registry. This typically just means removing the Register and Unregister methods from your add-in class. The AddInGuid property is in the same region as the registration functions, so if you intend on using this property in other areas of your add-in you’ll want to be careful not to delete it.

2. Create the manifest file

Create a new file in the same directory as your project file and name it “YourAddin.X.manifest”, where YourAddin will be replaced with the name of your add-in. Add the following to the manifest file. The portions highlighted in yellow need to be edited to match your add-in properties:

<?xml version="1.0"

      encoding="UTF-8"

      standalone="yes"?>

 

<assembly xmlns=

      "urn:schemas-microsoft-com:asm.v1"

          manifestVersion="1.0">

  <assemblyIdentity name="RegFreeVbAddin"

        version="1.0.0.0">

  </assemblyIdentity>

  <clrClass clsid=

      "{6e41e3fb-439a-4cbe-b648-ed6a47eeac8d}"

    progid="RegFreeVbAddin.StandardAddInServer"

    threadingModel="Both"

    name=

"RegFreeVbAddin.RegFreeVbAddin.StandardAddInServer"

    runtimeVersion="1.0">

  </clrClass>

  <file name="RegFreeVbAddin.dll"

               hashalg="SHA1">

  </file>

</assembly>

The “name” attribute of the clrClass element consists of three parts, separated by dots: Assembly.Namespace.ClassName   To make sure, you can retrieve the assembly name and root namespace from your project properties:

 

Note: The manifest file is not Unicode!

3. Embed the manifest during post-build

The next step is to add a post-build process to incorporate this manifest into your dll. The post-build process calls mt.exe which is a Microsoft utility that will embed the manifest into your AddIn’s dll. You define a post-build step through the Compile tab of the Application Properties dialog. On the Compile tab, click the “Build Events…” button and then on the “Build Events” dialog click the “Edit Post-build…” button. Finally enter the following string by replacing the correct Add-In name into the “Post-build Event Command Line” dialog, as shown below: call "%VS90COMNTOOLS%vsvars32" mt.exe -manifest "$(ProjectDir)RegFreeVbAddin.X.manifest" -outputresource:"$(TargetPath)";#2

Compile your project. This will cause the manifest to be embedded within your dll. If you get any errors when compiling, verify that the command line that you entered matches the one above. You can verify that the manifest has been correctly embedded by dragging the Add-In dll into Visual Studio. You should see the “RT_MANIFEST” folder, as shown below. Double clicking on the “2” icon will open a window to show you actual manifest data.

It appears that the “build events” functionality is not provided for Visual Basic Express. It is there for C# Express and of course regular versions of Visual Studio. If you use VB Express you can manually invoke the mt utility from the command line or create a batch file.

4. Create the .addin file

A requirement for all registry-free Add-Ins is to have an .addin file. With a registry based Add-In, Inventor relied completely on the registry to get information about the Add-In. The .addin file takes the place of the registry for this same information. The addin filename is in the form of Company.AddInName.Inventor.addin Below is the .addin file for my example Add-In with the portions to change highlighted:

<Addin Type="Standard">     <!--Created for Autodesk Inventor Version 16.0-->   <!--Override settings for ApplicationAddIn: RegFreeVbAddin-->     <ClassId>     {6e41e3fb-439a-4cbe-b648-ed6a47eeac8d}   </ClassId>     <ClientId>     {6e41e3fb-439a-4cbe-b648-ed6a47eeac8d}   </ClientId>     <DisplayName>     RegFreeVbAddin   </DisplayName>     <Description>     A Registry-free Inventor Addin   </Description>     <Assembly>     C:\Autodesk\Inventor\MyAddins\RegFreeVbAddin.dll   </Assembly>     <LoadOnStartUp>1</LoadOnStartUp>   <UserUnloadable>1</UserUnloadable>   <Hidden>0</Hidden>   <SupportedSoftwareVersionGreaterThan>     15..   </SupportedSoftwareVersionGreaterThan>   <DataVersion>1</DataVersion>   <UserInterfaceVersion>1</UserInterfaceVersion>   <LoadBehavior>0</LoadBehavior> </Addin>

For most AddIns, the ClassId (required) and ClientId (required) elements will be the same value, which is the GUID at the top of the StandardAddInServer class. The value of the DisplayName (required) element can be anything and is the name of the add-ins as shown in the AddIn Manager. The Description (required) element can also be anything and is the description of the add-in as shown in the AddIn Manager. The Assembly (required) element defines the name of the AddIn dll. It also defines the path to the dll. There are 3 ways to specify the location of the binaries: A full path including the dll name. Only the dll name. Inventor will look for this dll in the <InstallPath>\bin\ folder followed by the folder in which the .addin manifest was found (i.e. same folder as the .addin file). A relative path including the dll name. Inventor will search for the dll in the specified relative path starting at the <InstallPath>\bin\ folder followed by a search in the specified relative path starting at the folder in which the .addin manifest was found. The LoadOnStartUp (optional - obsolete) element specifies whether the add-in should load on start up. Assumed to be true if this value is not specified. Value can be 0 or 1. The UserUnloadable (optional) element specifies whether the user can unload the add-in. Assumed to be true if this value is not specified (i.e. user can unload the add-in). Value can be 0 or 1. The Hidden (optional) element defines whether the add-in is visible in the Add-In Manager or not. A value of 1 indicates that it is hidden, although the end-user can still right-click within the Add-In Manager and choose “Show hidden members” to display all add-ins. The SupportedSoftwareVersionXXX (optional) element specifies the version(s) of Inventor that the add-in should be available in. Combinations of these can be used. These values are ignored if the .addin file is located in a version-specific folder (i.e. the add-in is always available for that Inventor version). The DataVersion (optional) element specifies the version of add-in data contained within Inventor documents. To be used by add-ins that store migrating data in Inventor documents, indicated by “DocumentInterests”. The UserInterfaceVersion (optional) element specifies the version of the user interface of the add-in. Incrementing this version results in all of the addin’s UI getting cleaned up during Inventor start-up. The LoadBehavior (optional) element allows you to control a brand new feature of Inventor 2012: this will determine for which document type the addin will be loaded. Basically this feature will improve the start-up time of Inventor by delaying the loading of the addin the first time a specific document type is created or open, for example if your addin is only providing part-specific functionalities, you can choose to let Inventor load it only when the user will open his first part in the session. Here is a table that recaps the various values this flag can take and its effect:

LoadBehavior	Effect
0	Load on Start-up (not recommended)
1	Load when any document is open/created
2	Load when first Assembly is open/created
3	Load when first Presentation is open/created
4	Load when first Drawing is open/created
10	Load OnDemand

Assumed to be 0 if this value is not specified. Installer considerations: In the case you are building an installer to deploy your Add-In, you may wonder how you would handle the situation where you let the user select the location where they will install the Add-In dll itself, as the .addin file needs to reflect this path, and the answer is that you have 2 choices here: Do not let the user select a custom location for the install and provide a relative path or no path at all: Inventor will try to load the addin from the locations described above in the “Assembly” element section. Let the user select a custom location, in which case you will have to create a custom dll called from a custom action inside your installer that will dynamically perform the editing of the .addin file based on the selected path.

5. Choose a location for .addin file

Copy the .addin file to one of the following directories, depending on the scope of your add-in and the operating system.   Version Independent:    The presence of a .addin file in the following locations indicates that the AddIn should be loaded in multiple versions of Inventor based on the values of the “SupportedSoftwareVersionXXX” settings in the manifest file.   Windows XP: C:\Documents and Settings\All Users\Application Data\Autodesk\Inventor Addins\   Windows7/Vista: C:\ProgramData\Autodesk\Inventor Addins\     Version Dependent:    The presence of a manifest file in the following locations indicates that the AddIn should be loaded in a specific version of Inventor. The values of the “SupportedSoftwareVersionXXX” settings in the manifest file are ignored, if present. Windows XP: C:\Documents and Settings\All Users\Application Data\Autodesk\Inventor 2012\Addins\   Windows7/Vista: C:\ProgramData\Autodesk\Inventor 2012\Addins\     Per User Override:   The manifest file in the following locations can be created when per user overrides need to be saved. The settings in these manifest files override the setting values in the manifest files found in the ‘all users’ folder. The names of these override manifest files match the names of the “master” files. Windows XP: C:\Documents and Settings\<user>\Application Data\Autodesk\Inventor 2012\Addins\ Windows7/Vista: C:\Users\<user>\AppData\Roaming\Autodesk\Inventor 2012\Addins\ After following these steps your Add-In should be found and loaded by Inventor without any entries in the registry. Wayne Brill

Bitmaps without VB6 IconToIPicture

I’m very excited to be joining Brian as a co-author on this blog. It’s my first blogging experience and I’m eager to start writing about the many and varied things we’re doing with Inventor’s API!. To start out I thought it would be interesting to discuss a different way to create IPictureDisp needed for button images.

Having to reference Microsoft.VisualBasic.Compatibility and use Microsoft.VisualBasic.Compatibility.VB6.Support.IconToIPicture() to create an IPictureDisp works, but I always thought there should be a better way to create the image for the user interface. Also in a future release of Inventor there is a good chance that it will support .NET framework 4 and warning messages occur using IconToPicture(). (Inventor 2012 uses .NET 3.5).

I was happy to find a utility class that my colleague Philippe Leefsma recently created that uses stdole.IPictureDisp instead of IconToPicture().

This zip file has a project that creates an AddIn that adds a panel to the assemble tab on the assembly ribbon and a panel to the model tab on the part ribbon. This project is a completed lab used in one of the Inventor API trainings. (Originally using IconToIPicture).

Here is the class from the project that creates the IPicutreDisp. (See below for some instructions on how to use this class).

Imports System.Runtime.InteropServices

 

 Public NotInheritable Class PictureDispConverter

    <DllImport("OleAut32.dll", EntryPoint:= _

    "OleCreatePictureIndirect", ExactSpelling:=True, _

      PreserveSig:=False)> _

    Private Shared Function OleCreatePictureIndirect( _

      <MarshalAs(UnmanagedType.AsAny)> _

      ByVal picdesc As Object, _

      ByRef iid As Guid, _

      <MarshalAs(UnmanagedType.Bool)> _

      ByVal fOwn As Boolean) _

                         As stdole.IPictureDisp

    End Function

 

    Shared iPictureDispGuid As Guid = _

        GetType(stdole.IPictureDisp).GUID

 

    Private NotInheritable Class PICTDESC

        Private Sub New()

        End Sub

 

        'Picture Types

        Public Const PICTYPE_UNINITIALIZED As Short = -1

        Public Const PICTYPE_NONE As Short = 0

        Public Const PICTYPE_BITMAP As Short = 1

        Public Const PICTYPE_METAFILE As Short = 2

        Public Const PICTYPE_ICON As Short = 3

        Public Const PICTYPE_ENHMETAFILE As Short = 4

 

        <StructLayout(LayoutKind.Sequential)> _

        Public Class Icon

            Friend cbSizeOfStruct As Integer = _

              Marshal.SizeOf(GetType(PICTDESC.Icon))

            Friend picType As Integer = _

                PICTDESC.PICTYPE_ICON

            Friend hicon As IntPtr = IntPtr.Zero

            Friend unused1 As Integer

            Friend unused2 As Integer

 

            Friend Sub New(ByVal icon As  _

                           System.Drawing.Icon)

                Me.hicon = icon.ToBitmap().GetHicon()

            End Sub

        End Class

 

        <StructLayout(LayoutKind.Sequential)> _

        Public Class Bitmap

            Friend cbSizeOfStruct As Integer = _

              Marshal.SizeOf(GetType(PICTDESC.Bitmap))

            Friend picType As Integer = _

              PICTDESC.PICTYPE_BITMAP

            Friend hbitmap As IntPtr = IntPtr.Zero

            Friend hpal As IntPtr = IntPtr.Zero

            Friend unused As Integer

 

            Friend Sub New(ByVal bitmap As  _

                           System.Drawing.Bitmap)

                Me.hbitmap = bitmap.GetHbitmap()

            End Sub

        End Class

    End Class

 

    Public Shared Function ToIPictureDisp(ByVal icon As  _

       System.Drawing.Icon) As stdole.IPictureDisp

        Dim pictIcon As New PICTDESC.Icon(icon)

        Return OleCreatePictureIndirect(pictIcon, _

                             iPictureDispGuid, True)

    End Function

 

    Public Shared Function ToIPictureDisp(ByVal bmp _

        As System.Drawing.Bitmap) As stdole.IPictureDisp

        Dim pictBmp As New PICTDESC.Bitmap(bmp)

        Return OleCreatePictureIndirect(pictBmp, _

                              iPictureDispGuid, True)

    End Function

End Class

How to use the PictureDispConverter class.

1. Add a reference to stdole (On the .NET tab of the Add Reference dialog)

2. In your project add a new class and copy the code above into the class.

3. Create a resource in the project.

4. Call  PictureDispConverter.ToIPictureDisp() and pass in the resource. Here is the code from the attached project that does this.

   Dim mIPictureDisp1 As IPictureDisp = _

         PictureDispConverter.ToIPictureDisp _

                                      (My.Resources.Tools)

 

   Dim mIPictureDisp2 As IPictureDisp = _

         PictureDispConverter.ToIPictureDisp _

                                      (My.Resources.wbTest)

 

Wayne Brill

Upgrading your Add-Ins to Support the Ribbon User Interface

I thought I should share some more of the work that was done for the last Autodesk University.  This class covered how to upgrade your add-in to use the ribbon user interface.  It was one of the new virtual classes and the video is available.  However, the paper contains all of the information in the video plus some additional material that I didn’t have time for in the video.

The paper answers the following questions:

1. From a user’s perspective, what is the ribbon user interface?
2. Can my VBA macros work with the ribbon?
3. Will my existing add-ins work with the ribbon?
4. How does the API support the ribbon?
5. What do I need to consider when adding my buttons to the ribbon?
6. What do I do about the classic interface?

Below are links to the paper and some sample programs.

Paper
Sample Programs

How to Write an Inventor Add-In

I’ve posted similar material previously but this is more complete and up to date.  The attached paper and code is from a presentation at this past Autodesk University.  I believe the paper can be used by itself and is not dependent on you having been at the presentation.  The primary focus is on someone that’s now using VBA and would like to move to add-ins, although it will also serve as a good general introduction for anyone that wants to learn more about add-ins.

The paper tries to answer the following questions:

1. What is an Add-In?
2. Why would you want to create an Add-In?
3. How do you create an Add-In?
4. How do you convert your VBA macros?
5. How do you execute an Add-In command?
6. How do you debug an Add-In?
7. How do you deploy an Add-In?

The languages used are VB Express 2008 and Visual Basic from Visual Studio 2008.  It also covers the differences you’ll run into between VBA and VB.Net.

Paper
Sample Files