Advanced API: Using Persistent IDs to Locate Objects

Blog 3.13.2012 4 Comments

Fundamental to writing macros and add-ins with the SolidWorks API is knowing how to get the pointer to a particular object.  In some cases, this is a simple.  If you need a selected object’s pointer then you just use ISelectionManager::GetSelectedObject6.  If you need the name of a feature called “CutExtrude1” then you would just use IPartDoc::FeatureByName.  These methods, however, assume that you know the name of that object.  This isn’t always the case.  What to do then?

First, you need to programmatically locate the object.  The most common way is to traverse the FeatureManager tree (in the case of a feature or component) or traverse the geometry or topology itself (in the case of a face, edge, vertex, etc.).  Once you have the object, however, how does your program “remember” it for later use?  You could store its name or perhaps its location, but depending on the object this could be very tedious.

Instead, a much easier option is to use “persistent IDs”.  Persistent IDs are a unique identifier for any selectable object.  According to the API Help, “The reference IDs persist for the objects in the model document across SolidWorks sessions. Other applications can use persistent reference IDs to locate objects at runtime.”  This means that, unless you remove and then recreate that object, you can always locate that object so long as you have its ID.

Obtaining an object’s ID is very simple.  Just use IModelDocExtension::GetPersistReference3, which returns an object containing the persistent ID.  (Fun fact: Think your password is unique?  A persistent ID has 297 digits.)  Later, even if its a different SolidWorks session with a different program, you can re-obtain that object’s pointer using IModelDocExtension::GetObjectByPersistReference3.

Want to see how easy they are to use?  Open up any existing part or create a new one and add at least one feature.  Paste the following code in a new VBA macro and set a breakpoint on the line right after IModelDoc2::ClearSelection2 is used.  Now, select a feature in the FeatureManager tree and run the macro.  When your code breaks, look at your part and notice that nothing is selected.  Click Run to continue the code, and then look at the part again.  Why is the feature re-selected?  The persistent ID for that feature was obtained right before the selection was cleared.  On the line following IModelDoc2::ClearSelection2, the pointer was re-obtained using the persistent ID and then re-selected using appropriate Select method.

Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swSelMgr As SldWorks.SelectionMgr
Dim swObj As SldWorks.Feature
Dim swRef As Variant
Sub main()
    Set swApp = Application.SldWorks
    Set swModel = swApp.ActiveDoc
    Set swSelMgr = swModel.SelectionManager
    Set swObj = swSelMgr.GetSelectedObject6(1, -1)
    swRef = swModel.Extension.GetPersistReference3(swObj)
    swModel.ClearSelection2 True
    Set swObj = swModel.Extension.GetObjectByPersistReference3(swRef, Empty)
    swObj.Select2 False, Empty
End Sub

You can make this code work with any selectable object.  Just change the data type for swObj to something else—a face, a note, a component, etc.—and then make sure that you use the correct Select method for that object. A version that allows you to re-select multiple entities using persistent IDs is found here.

As you can see, this technique for locating objects can be far simpler than using entity names or attributes, because you don’t even need to assign the ID—it’s already there.  Indeed, many people wrongly use attributes when persistent IDs should be used.  Attributes will be discussed in part two of this series.


Want to keep up with new blog posts, videos, and macros we create each month? Sign up for our newsletter!

Leave Comment

Free PDF: 23 VBA Errors and How To Fix Them

Blog 3.6.2012 No Comments

Download the free PDF here

If you’ve done any significant amount of programming with the SolidWorks API, no doubt you’ve run into compile or run-time errors. In my thousands of hours working with the API, here are the 23 I encounter the most:

  • “Compile error: variable not defined”
  • “Run-time error ’450?: Wrong number of arguments or invalid property assignment”
  • “Run-time error ’91?: Object variable or With block variable not set”
  • “Run-time error ’5?: Invalid procedure call or argument”
  • “Run-time error ’13?: Type mismatch”
  • “Code execution has been interrupted”
  • “Run-time error ’438?: Object doesn’t support this property or method”
  • “Run-time error ‘-2147417848 (80010108)’: Automation error The object invoked has disconnected from its clients”
  • “Run-time error ’98?: A property or method call cannot include a reference to a private object, either as an argument or as a return value”
  • “Compile error: Method or data member not found”
  • “Run-time error ’424?: Object required”
  • “Compile error: Expected user-defined type, not project”
  • “Run-time error ‘-2147417851 (80010105)’: Automation error The server threw an exception.”
  • “Run-time error ’445?: Object doesn’t support this action”
  • “Compile error: Can’t find project or library”
  • “Compile error: User-defined type not defined”
  • “Run-time error ‘-2147417848 (80010108)’: Method ‘IDisplayWireFrameXOR’ of object ‘IBody2’ failed”
  • “Compile error: ByRef argument type mismatch”
  • “Compile error: The code in this project must be updated for use on 64-bit systems. Please review and update Declare statements and then mark with the PtrSafe attribute.”
  • “Could not load some objects because they are not available on this machine.”
  • “Run-time error ‘53’: File not found:
  • “Compile error: Expected variable or procedure, not project”
  • “Compile error: Object library feature not support”

Figuring out what these errors mean and how to fix them can be a real challenge. That’s why I created a free PDF, VBA Debugging Tips for SolidWorks API Programmers, that addresses each of these errors—their causes AND their solutions. This PDF also covers basic debugging tips that will be helpful for those new to SolidWorks API programming.

Let me address just one of these right now. The third error listed is “Run-time error ’91?: Object variable or With block variable not set”. This usually occurs when you are trying to use an API call belonging to an interface that you have not yet accessed. So for example, try typing this in your VB Editor and running it:

Dim swApp As SldWorks.SldWorks
    Sub main()
    swApp.SendMsgToUser "Hello world!"
End Sub

You should get the aforementioned error:

The error is occurring because the swApp object variable was never set. Consequently we can remedy the problem rather easily by simply adding one line to our macro:

Dim swApp As SldWorks.SldWorks
Sub main()
    Set swApp = Application.SldWorks
    swApp.SendMsgToUser "Hello world!"
End Sub

Likewise, you’ll also get the same error if you leave out the Set keyword. (In Visual Basic for Applications, assigning a reference to an object variable requires the Set keyword. This isn’t the case in other languages, however.)

Sometimes you will get this error message in situations where the solution is less obvious. Chances are you doing one of the following:

  1. You accidentally killed the pointer you were intending to use. For example, if you closed out a model and then tried using the IModelDoc2 pointer to that document that you had previously obtained.
  2. You are using a method incorrectly, so that the interface you thought was going to be returned was never actually returned. For example, if you use IAssemblyDoc::AddMate3 to create a concentric mate between two planar faces, the API call will obviously fail to return the IMate2 object. Therefore, when you try to later use an IMate2 member with the variable that you thought contained an IMate2 object, you get this error.

In conclusion, I think we can all agree that the least enjoyable aspect of programming is debugging. Reduce the time you’ll spend debugging by using my free SolidWorks API debugging PDF and also by taking advantage of our free SolidWorks API training. Lastly, please let me know in the comments below of any other errors that you think I should include in the PDF.

Happy coding!

Want to keep up with future content, webinars, and special offers? Sign up for our newsletter.

Leave Comment

Jedi skills : How to create bodies without using features

Blog 2.29.2012 No Comments

Yes, it’s true. You can create bodies “on-demand” without using features—using the SolidWorks API, of course. How does this magic happen? Enter in a rarely used but very powerful interface called IModeler. This interface contains no less than 30 members (not including obsolete members) for creating every kind of solid body, surface body, and curve you can think of—all without clogging up your feature tree. Best of all, since these temporary bodies are still true bodies, any IBody2 member can be used on them.

Why are they temporary? Because as soon as the IBody2 object for the temporary body becomes Nothing, *poof*. They’re gone. You ask, “What’s the point, then?” Consider these scenarios:

1. Previews. The most obvious use here would be a macro feature preview, but a preview could be used in other contexts as well. Temporary bodies can be easily updated with new user input, and the programmer can choose not to make the temporary body selectable—just like you’re familiar with already when previewing a feature.

2. Performance. IModeler generates temporary bodies far faster than standard features. Combine this with the default invisibility of temporary bodies and the ability to use IBody2 functions on them, and you have a great tool for calculating mass and volume properties very quickly and without the user knowing. For example, perhaps your macro or add-in needs to calculate the volume inside of a pressure vessel. Using IModeler you could create a body that consumes the pressure vessel, run a subtract operation using IBody2::Operations2 using the pressure vessel as the tool body, delete out the unnecessary bodies, and then find the remaining volume.

Finally, in the event that you do want the temporary body to become a “normal” feature, no problem. That is what IPartDoc::CreateFeatureFromBody3 is for. That brings us to our final use of IModeler:

3. Macro features. A macro feature is a custom feature and consequently any body produced by this feature cannot come from a standard feature, hence the need for IModeler.

Want to see a simple example IModeler in action? Try out this code with a blank part document open:

Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swModeler As SldWorks.Modeler
Dim swBody As SldWorks.Body2
Dim swFeat As SldWorks.Feature
Dim swPart As SldWorks.PartDoc
Sub main()
    Set swApp = Application.SldWorks
    Set swModel = swApp.ActiveDoc
    Set swModeler = swApp.GetModeler
    Dim dblData(8) As Double
    dblData(0) = 0
    dblData(1) = 0
    dblData(2) = 0
    dblData(3) = 1
    dblData(4) = 0
    dblData(5) = 0
    dblData(6) = 0.1
    dblData(7) = 0.1
    dblData(8) = 0.1
    Set swBody = swModeler.CreateBodyFromBox(dblData)
    Set swPart = swModel
    Set swFeat = swPart.CreateFeatureFromBody3(swBody, False, 0)
End Sub

The result should be a cube created instantly—without creating any sketches or using any features.

Want to learn more? Our video tutorial on temporary bodies, found in our complete VBA course, will show you how to do the following:

  • How to display temporary bodies (without converting them to permanent bodies)
  • How to check temporary bodies for faults
  • How to perform boolean operations (e.g., add, subtract, combine) on temporary bodies
  • How to change the color of temporary bodies
  • How to make temporary bodies unselectable

In the very near future we’ll be posting a video showing how to use temporary bodies in macro feature previews, so check back soon.

Happy coding,

PS: Don’t forget that our 20% off discount lasts only until March 10th! Just use coupon code “sww2012”.

Want to keep up with future macros, videos, and live training classes? Sign up for our newsletter.

Leave Comment