In a previous post I discussed several way to access the thumbnail image that’s associated with each document.  One of these ways is to use the ThumbnailView component.  I received a question recently regarding the ThumbnailView component not working as expected.  After quite a bit of digging and some testing I believe I know what the problem is and how to fix it.

I believe this an issue only if you’re using .Net (VB or C#) and are using 64-bit Windows.  I don’t think there are problems with any other configurations but if there are, please let me know.

COM and .Net on a 64-Bit OS Overview
Before I describe the solution, I think it might be worth taking a minute to describe what’s happening when you use a COM component (the thumbnail view component in this case) from .Net program on a 64-bit system.  The picture below attempts to show all of the various pieces that need to play together to get this work.  First, is the COM component itself.  The thumbnail viewer was created using C++ and the resulting dll is compiled for either 32 or 64-bit.  On a 32-bit system you can only use 32-bit components.  On a 64-bit system you can use either 32 or 64-bit components because 64-bit windows supports an emulator that is able to run 32-bit applications.  COM dll components run within the process of the program using it and a 32-bit component can only run within a 32-bit process and a 64-bit component can only run within a 64-bit process.

The registry is used because COM components can be located anywhere on a computer but other programs need to be able to know they’re available and where they’re located.  The components make themselves known by adding information to the registry.  There are separate areas in the registry where 32-bit and 64-bit components register themselves.

Another piece that makes the 32-bit vs. 64-bit issue described above even more confusing is that when writing a .Net program you can specify that the runtime will be compatible with 32-bit (x86), 64-bit (x64), or “Any CPU” (both 32 and 64-bit).  The “Any CPU” option is the interesting, and confusing, option.  It’s the option I almost always use.  The reason that .Net can support the “Any CPU” option is that when you compile your program, .Net compiles your program into MSIL (Microsoft Intermediate Language) which is a CPU independent set of instructions.  When your program is run, it is converted by the JIT (Just-In-Time) compiler into native code. This means that even if your program was compiled for “Any CPU”, when it runs it will actually be running as a native 32-bit or 64-bit application.

Because the COM component runs in-process to your application it must match the bitness of the running application.  For example, if you compile your application for “Any CPU” and run your program on a 64-bit machine, the .Net Framework will run it as a true 64-bit application and the 64-bit version of the thumbnail viewer will be required.  If you compile your application for 32-bit and run it on a 64-bit machine, it will run as a 32-bit app and will require the 32-bit version of the thumbnail viewer.  If the correct version of the COM component isn’t available, it will fail to run.

In addition to your program and the COM component, there is one other piece needed when using a COM component with .Net; an Interop assembly.  Your .Net program can’t directly call a COM component.  To provide support for COM, .Net uses the concept of Interop assemblies which are .Net components that provide a .Net interface to a COM component.  When you use the COM component, your program is actually calling functions in the interop assembly, which translates those calls and makes the equivalent call in the COM component.  The Interop serves as a wrapper for the COM component making it compatible with .Net.  These interop assemblies are dll’s and can also be created for 64-bit, 32-bit, or agnostic (equivalent to “Any CPU”).  But like the component, it must also match the bitness of the program it will be running within.

In summary, there are three runtime pieces; the COM component, the .Net Interop, and your program.  If you’re running on a 32-bit system, all of them must be 32-bit.  If you’re running on a 64-bit system you can run either 32-bit or 64-bit but all of the pieces must be 32-bit or 64-bit.  You can’t mix and match the bitness.

The Problem
When programming with .Net and using a COM component, it’s somewhat transparent that there is an interop assembly involved.  When you reference the COM component into your project, Visual Studio automatically creates the interop behind the scenes.  The problem is that it’s creating a 32-bit compatible interop.  If you’re creating a 32-bit application, then everything is fine, but for a 64-bit application it’s not going to work.

I found the problem by doing some research on the web and discovering this article on a Microsoft support site that gave me the clue I needed.  It also indicates that this is fixed in VS 11.

The Fix
Here’s the fix that I’m using to get this to work.  You need to manually create the interop for the thumbnail viewer component.  By manually creating it, you can specify the machine type that it’s compatible with.  In this case either “x64” or “Agnostic” will work because at runtime on an x64 machine they will both result in true X64 machine code.

TlbImp.exe InventorThumbnailView.dll
           /machine:Agnostic 
           /namespace:InventorThumbnailViewLib
           /out:Interop.InventorThumbnailView.dll

Here’s a link to a text file that has the complete command line, with the full paths, so you can just copy and past this into a DOS command window.  You will need to edit the path for the output interop dll to where your project is.

Once you’ve created the interop, Use the References command in Visual Studio to reference it into your project.  Use the Browse tab on the References dialog so you can browse and select the interop dll.  You’ll reference this instead of the InventorThumbNailView.dll file.  Now it should all work. 

Below is some code from a very simple Windows Forms project that I created.  After creating the new project, I added a picture box control (with the SizeMode property set to “StretchImage”) and a button to the dialog.  I also added an open file dialog.  Finally, I added a reference to the .Net component “stdole”.  Below is the code that’s contained within the Click event of the button.  It uses the file dialog to get the filename of an Inventor file, uses the thumbnail view component to get the thumbnail from the Inventor file and then displays it.  The component returns the image as an IPictureDisp object.  Next, it converts this object to a .Net Image object, which it finally assigns to the picture box.  See below for some more discussion about this conversion process.

' Code in the button Click event.
With OpenFileDialog1
    .Filter = "Inventor Files (*.ipt;*.iam;*.idw)|*.ipt;*.iam;*.idw"
    If .ShowDialog() = System.Windows.Forms.DialogResult.OK Then
        ' Create an instance of the thumbnail viewer component.
        Dim thumbviewer As New _
                           InventorThumbnailViewLib.ThumbnailProvider

        ' Use the component to get the thumbnail.
        Dim pic As stdole.IPictureDisp = Nothing
        Dim handle As Long = 0

        ' Use workaround to make sure handle is a positive number.
        ' Otherwise the call to PictureDispToImage will fail.
        Do
            pic = thumbviewer.GetThumbnail(.FileName)
            handle = pic.Handle
        Loop While handle < 0

        ' Convert the IPictureDisp into an Image to 
        ' display it in the picture box.
        Dim img As Image = AxHostConverter.PictureDispToImage(pic)
        PictureBox1.Image = img
    End If
End With

The object that represents a bitmap image in COM is an IPictureDisp object, (which is defined in the stdole library).  .Net represents a bitmap image using the Image object.  This means there needs to be a conversion from an IPictureDisp objet to an Image object to be able to use the returned bitmap in .Net.  There is a Visual Basic compatibility library that contains routines to do this.  Unfortunately, if you use them with .Net 4, you’ll get a warning message that these functions are obsolete and are only supported on 32-bit.  You can read more here: http://go.microsoft.com/fwlink/?linkid=160862.

To avoid these warnings and possible problems in the future you’ll need to use something else.  Unfortunately, Microsoft hasn’t provided a simple alternative.  Below is a class that exposes some functions to do this conversion from one type to the other.  I wraps some internal functionality on another Microsoft class to it can be used in a general way.  To use it in your project, just copy the class below into your project.  The PictureDispToImage function defined in this AxHostConverter class is used in the code above.

There’s also some funny code in the example above that’s a workaround to a problem I found while testing.  When testing, it would periodically fail to do the conversion.  The failure seemed random with a “A generic error occurred in GDI+” failure.  I accidentally discovered that the failure was occurring whenever the Windows handle being provided by the IPictureDisp object was negative.  The workaround I put in the code above keeps getting an new IPictureDisp until the handle is a positive number.  I stress tested this through several thousand iterations and the most it ever looped to get a positive number was 10, so I think the chance of this being an endless loop is too small to worry about.  About 85% the first return is positive, another 10% took two calls, and the remaining 5% is 3 or more calls.  I believe the cause of this problem is that the number is actually an unsigned int, but it’s being treated as a regular int which results in a negative number for large numbers.  Anyway, this seems to work around the problem.

' Utility class that provides support for converting between
' IPictureDisp and Image objects.
Friend Class AxHostConverter
    Inherits AxHost

    Private Sub New()
        MyBase.New("")
    End Sub

    Public Shared Function ImageToPictureDisp( _
                    ByVal objImage As Image) As stdole.IPictureDisp
        Return DirectCast(GetIPictureDispFromPicture(objImage), _
                          stdole.IPictureDisp)
    End Function

    Public Shared Function PictureDispToImage( _
                  ByVal pictureDisp As stdole.IPictureDisp) As Image
        Dim objPicture As System.Drawing.Image
        objPicture = CType(GetPictureFromIPicture(pictureDisp), _
                           System.Drawing.Image)

        Return objPicture
    End Function
End Class

One final thing to remember is that you’ll need to deliver the interop with your program.  Your program has two dependencies which you’ll need to deliver in addition to your exe; the thumbnail view component, (which also needs to be registered), and the interop dll.

This is a continuation of the getting started tutorial that’s discussing the creation of a new command to draw a slot.  In this installment I discuss drawing geometry in a sketch.

When creating sketch geometry using the API, there are a couple of concepts that are important to understand that aren’t very obvious when you create sketches interactively.  Let’s look at what you really have when you draw two lines in a sketch.  You can see from the picture below it just looks like two lines and nothing else.

 

If you know what to look for, you’ll also notice something else.  If you move the mouse over the end of the lines, a point is displayed, as shown below.  At first you might think this is just a handle being displayed to indicate that you can drag the end of the line.  It’s not a handle, it’s a real sketch point that’s being displayed. 

In fact, to better see these are real points you can select a point and using the context menu, change the display style of the point to a center point.  With this display style it remains visible all the time and not just when the cursor is over it.  The picture below shows all three of the points being displayed with a center point style.

The thing to learn from this is that all sketch geometry is always associated to  sketch points.  Sketch geometry doesn’t exist on its own.  The position of sketch geometry is controlled by the position of the points.  It’s like the geometry is fastened to the points and if the points move the geometry attached to them also moves. 

Another very important concept is that the two lines are connected by the fact that they share the same point.  Both lines are attached to the same point.  That’s how Inventor determines connected curves in a profile.  We’ll see an example of this later in this post.

Below is a picture of the two lines after placing a fillet.  The geometry consists of two lines and an arc.  The position of each of the lines is still defined by two sketch points and the arc shares the sketch points where it connects to the lines.  In addition, the arc has an additional sketch point that defines its center.

When you interactively draw a sketch, Inventor automatically creates these points behind the scenes.  It also automatically deletes them when the associated geometry is deleted.  When using the API it’s possible to have it automatically create these points too, but without understanding these concepts of how geometry is connected to points and each other by sharing points it’s easy to get results you weren’t expecting.  When interactively drawing a sketch, it’s natural to get the correct result because Inventor infers connections based on where you click the mouse.  When using the API, none of this inference can take place because you’re not moving the mouse over the geometry.

The code below creates a sketch line on an existing sketch.  You can paste this into the bottom of the sub from the previous post in this series. 

' Get a reference to the TransientGeometry object.
Dim tg As Inventor.TransientGeometry = invApp.TransientGeometry

' Get a reference to the SketchLines collection.
Dim lines As Inventor.SketchLines = sketch.SketchLines

' Draw a line between (0,0) and (4,0).
Dim line1 As Inventor.SketchLine
line1 = lines.AddByTwoPoints(tg.CreatePoint2d(0, 0), _
                             tg.CreatePoint2d(4, 0))

The first thing this does is get a reference to the TransientGeometry object. This is a utility object in the API that lets you create various types of geometry.  However, the geometry created is not ever displayed or saved by Inventor, which is why they are called transient.  These objects are simply the mathematical definition of the geometry and are not visible entities.  I’m using it in this case to create two coordinate points to define the end points of the line.  The CreatePoint2d method creates a transient 2d point.  The Point2d object is a simple API object that wraps the x-y coordinates of a point in 2d space.  In Inventor’s API, instead of passing two values to define x-y coordinates a Point2d object is used instead.  There’s also a Point object which wraps x-y-z coordinates for a 3d point.  When working with a sketch you want to make sure you’re using the CreatePoint2d method and not the CreatePoint method.  It’s a common mistake.

The next thing the program above does is get the SketchLines collection.  In a previous post I briefly discussed collection objects.  The SketchLines object lets you access all of the lines on the sketch and it supports add methods to let you create new lines.  This examples uses the AddByTwoPoints method to create a new sketch line.

The final section of the code above creates the new line.  A variable is declared with the type of SketchLine and the newly created line is assigned to the variable.  The AddByTwoPoints method takes to points as input.  These can either be coordinate points (defined by a Point2d object as in the example above) or they can be existing SketchPoint objects, which you’ll see demonstrated below.

Another thing that’s important to understand are the units that Inventor uses. Internally, Inventor is consistent in the units it uses.  Lengths are always defined in centimeters and angles are always defined in radians.  It doesn’t matter what units the user has specified as their document units.  The API is consistent with the Inventor internal units.  When you create or query geometry, any length or coordinate values will always be in centimeters and any angles will always be in radians.  The example above creates a 4 centimeter long line starting from the origin and going in the sketch X direction.  We’ll see in a later post how to deal with user defined units.

Below is some code that creates a second and third line to create a triangle.

' Draw a line between (4,0) and (4,3).
Dim line2 As Inventor.SketchLine
line2 = lines.AddByTwoPoints(tg.CreatePoint2d(4, 0), _
                             tg.CreatePoint2d(4, 3))

' Draw a line between (4,3) and (0,0).
Dim line3 As Inventor.SketchLine
line3 = lines.AddByTwoPoints(tg.CreatePoint2d(4, 3), _
                             tg.CreatePoint2d(0, 0))

The resulting geometry is shown below on the left.  If I try to create an extrusion using this sketch I can’t select the triangle, but only the individual lines.  That’s because each line has it’s own unique pair of sketch points for its end points, instead of sharing a single point between two lines.  This becomes obvious if I drag any of the end points, the triangle pulls apart, as shown in the picture on the right.

The code below is a variation of the previous code but creates a set of connected lines.  The difference is that instead of defining new coordinates for the end of each line it uses the EndSketchPoint and StartSketchPoint properties of the SketchLine object to get the sketch points from the existing lines.

' Draw a line between (0,0) and (4,0).
Dim line1 As Inventor.SketchLine
line1 = lines.AddByTwoPoints(tg.CreatePoint2d(0, 0), _
                             tg.CreatePoint2d(4, 0))

' Draw a second line from the end of the previous line to (4,3).
Dim line2 As Inventor.SketchLine
line2 = lines.AddByTwoPoints(line1.EndSketchPoint, _
                             tg.CreatePoint2d(4, 3))

' Draw a line connecting the last point to the first point.
Dim line3 As Inventor.SketchLine
line3 = lines.AddByTwoPoints(line2.EndSketchPoint, _
                             line1.StartSketchPoint)

 

The approach to creating sketch geometry that I’ve had the best personal success with is to create the sketch points first and then use those as input when creating the various sketch entities.  It’s easier for me to visualize the points I need if I map it out before hand and having the map helps to eliminate mistakes in my code.  For example, below is an example of what I sketched up to help me visualize the points that will be needed to create the slot.  Remember that arcs and circles require a sketch point at their center.  I’ve numbered the points starting with zero.  Those numbers will correspond to indices in an array in my program.

Below is the code that demonstrates this approach.  It begins by creating the sketch points and then it uses those points to create the sketch geometry.  It becomes a dot-to-dot exercise to draw the geometry.  This examples illustrates lines and arcs, but all of sketch geometry uses the same concepts.  You’ll just be using different collection objects and different add methods within those collections.

' Get a reference to the SketchPoints collection.
Dim points As Inventor.SketchPoints = sketch.SketchPoints

' Get a reference to the SketchLines collection.
Dim lines As Inventor.SketchLines = sketch.SketchLines

' Get a reference to the SketchArcs collection.
Dim arcs As Inventor.SketchArcs = sketch.SketchArcs

' Create the sketch points.
Dim pointArray(5) As Inventor.SketchPoint
pointArray(0) = points.Add(tg.CreatePoint2d(0, 1), False)
pointArray(1) = points.Add(tg.CreatePoint2d(0, 0), False)
pointArray(2) = points.Add(tg.CreatePoint2d(0, -1), False)
pointArray(3) = points.Add(tg.CreatePoint2d(4, -1), False)
pointArray(4) = points.Add(tg.CreatePoint2d(4, 0), False)
pointArray(5) = points.Add(tg.CreatePoint2d(4, 1), False)

' Draw the geometry.
Dim arc1 As Inventor.SketchArc
arc1 = arcs.AddByCenterStartEndPoint(pointArray(1), pointArray(0), _
                                     pointArray(2))

Dim line1 As Inventor.SketchLine
line1 = lines.AddByTwoPoints(pointArray(2), pointArray(3))

Dim arc2 As Inventor.SketchArc
arc2 = arcs.AddByCenterStartEndPoint(pointArray(4), pointArray(3), _
                                     pointArray(5))

Dim line2 As Inventor.SketchLine
line2 = lines.AddByTwoPoints(pointArray(5), pointArray(0))

The result after running the program is shown below, which is what’s expected.  Because the entities share sketch points at the connections, Inventor sees this as being closed so it can be used as input to create an extrusion.

However, if you try and edit the sketch by dragging the points it may not behave as you expect, as shown in the picture below.  This is because there aren’t any constraints to define the behavior.  Interactively, constraints are inferred during the sketching process by how you move your mouse, which can’t happen when using the API.  I’ll discuss adding constraints in an upcoming post.

Note: One issue that I just discovered while writing this post is that the AddByCenterStartEndPoint method is not associating the input center sketch point with the new arc, but is instead creating a new point at that position.  This is not expected behavior and I’ll discuss how you can work around this issue in a later post.  Just know that when you see the extra center points that you didn’t do anything wrong.

-Brian