{"id":11617,"date":"2022-09-10T12:02:59","date_gmt":"2022-09-10T10:02:59","guid":{"rendered":"https:\/\/cadbooster.com\/?p=11617"},"modified":"2024-03-16T13:40:32","modified_gmt":"2024-03-16T12:40:32","slug":"entities-and-getcorresponding-in-the-solidworks-api","status":"publish","type":"post","link":"https:\/\/cadbooster.com\/nl\/entities-and-getcorresponding-in-the-solidworks-api\/","title":{"rendered":"Entities and GetCorresponding in the SOLIDWORKS API (part 7)"},"content":{"rendered":"

In this blog post, you’ll find<\/h3>\n
    \n
  1. What are entities?<\/a>\n
      \n
    1. All interfaces that implement IEntity<\/a><\/li>\n
    2. What are loops?<\/a><\/li>\n
    3. What are features?<\/a><\/li>\n
    4. Casting to and from entities<\/a><\/li>\n<\/ol>\n<\/li>\n
    5. Entities and their Persistent Reference ID<\/a><\/li>\n
    6. How to get an entity’s object<\/a><\/li>\n
    7. How to select a vertex, face or edge: via its entity<\/a><\/li>\n
    8. What are Safe Entities?<\/a><\/li>\n
    9. How to assign an attribute to an entity<\/a>\n
        \n
      1. What are attributes?<\/a><\/li>\n
      2. Parameter types within attributes<\/a><\/li>\n
      3. How to create an attribute<\/a><\/li>\n
      4. How to retrieve an attribute from an entity<\/a><\/li>\n<\/ol>\n<\/li>\n
      5. Understanding the scope of an entity: does it belong to a part or a component?<\/a>\n
          \n
        1. Models versus components<\/a><\/li>\n
        2. Drawing components<\/a><\/li>\n
        3. An entity is only valid in the current model<\/a><\/li>\n<\/ol>\n<\/li>\n
        4. How to use GetCorresponding to get a part entity in an assembly<\/a>\n
            \n
          1. How to convert a part entity to a component entity<\/a><\/li>\n
          2. How to convert a component entity to a part entity<\/a><\/li>\n
          3. How to get an entity in a drawing view from a part entity<\/a><\/li>\n<\/ol>\n<\/li>\n
          4. All blog posts in this series<\/a><\/li>\n<\/ol>\n

            1. What are entities?<\/h3>\n

            Every 3D model is built up from vertices (points), edges and faces. In the SOLIDWORKS API, we name these objects Entities<\/em>. They all implement the IEntity<\/a> interface because they share common properties and methods.<\/p>\n

            1.1. All interfaces that implement IEntity<\/h4>\n

            This is the complete list of all interfaces that implement IEntity:<\/p>\n

            \"interfaces<\/p>\n

            I think these five objects are the building blocks of geometry:<\/p>\n

              \n
            1. Vertices\/points are the smallest building blocks: IVertex<\/a><\/li>\n
            2. Two vertices create a straight edge: IEdge<\/a><\/li>\n
            3. One or more edges or vertices make up a loop: ILoop2<\/a><\/li>\n
            4. One or more loops make up a face: IFace2<\/a><\/li>\n
            5. One or more faces create a feature: IFeature<\/a><\/li>\n<\/ol>\n

              I don’t fully understand why loops and features are in the list of entities yet. And because the SOLIDWORKS API docs never explain what an object is<\/strong>, just what it does<\/strong>, we’ll have to figure that out ourselves. This is how I understand it now:<\/p>\n

              1.2. What are loops?<\/h4>\n

              I haven’t used ILoop2 in my six years of SOLIDWORKS programming, so you probably won’t need them unless you are creating your own geometry. But from what I have read, SOLIDWORKS creates loops from a list of edges and\/or vertices. Even one vertex can make up a loop.<\/p>\n

              So they create loops from edges and vertices, then create faces from these loops. Every face has at least one loop, but it can have more than one. A face with two holes in it has three loops, one being the outer loop<\/a>.<\/p>\n

              1.3. What are features?<\/h4>\n

              I have only looked at features as the items in the feature tree. But I think features are included in the list of entities because a feature might create<\/em> a bunch of faces. An extruded circle creates three faces, for example. And when you call IFeature.GetFaces<\/a> on a draft feature, SOLIDWORKS returns an empty array because a draft feature creates no new faces.<\/p>\n

              According to the SOLIDWORKS Object Model PDF, that you can download here<\/a>, IFeature doesn’t even implement IEntity. But I think that is a mistake in the docs.<\/p>\n

              1.4. Casting to and from entities<\/h4>\n

              Because all the interfaces above implement IEntity, you can cast (aka convert) the detailed object back to an entity to make use of IEntity properties and methods<\/a> (aka members). In VBA:<\/p>\n

              dim swFace as Face2\r\nset swFace = something 'Get the face from somewhere\r\n\r\ndim swEntity as Entity\r\nset swEntity = swFace 'This is called casting the face to an entity. This works because IFace2 implements IEntity\r\n\r\ndim selected as Boolean\r\nselected = swEntity.Select4(false, Nothing) 'This works in VBA and C#\r\n\r\n'Alternative method: call the Entity method directly\r\nselected = swFace.Select4(false, Nothing) 'This works in VBA, although it does not compile. It also doesn't compile in C# because IFace2 has no Select4 method.<\/pre>\n
              You can also cast an Entity to a Face2 to use all the members in IFace2<\/a>, but you have to make sure the entity is actually a face by calling IEntity.GetType<\/a> first.<\/p>\n
              In C#, you have to make explicit casts when casting to and from entities:<\/p>\n
              IEntity entity = x; \/\/get an entity from somewhere\r\nvar face = (Face2) entity; \/\/ cast an entity to a face\r\nvar entity2 = (IEntity) face; \/\/ cast a face to an entity\r\nvar entity3 = face as IEntity; \/\/ also works<\/pre>\n
              Normally, when working in C#, you can cast implicitly when a type implements an interface. But the SOLIDWORKS API is different, and they talk about it here<\/a>. I still don’t fully understand their explanation because they are talking about three programming languages in one post. My main takeaway is that SOLIDWORKS isn’t written in C# and inheritance works differently in C++ (I think it’s written in C++, at least). That is also why we have to use Interop (interoperability) DLLs to talk to SOLIDWORKS.<\/p>\n
              2. Entities and their Persistent Reference ID<\/h3>\n
              All selectable objects in the SOLIDWORKS API have a\u00a0Persistent Reference ID<\/em>. I call them Persistent IDs for short. I explain them in detail in Persistent ID, sketch segment ID in the SOLIDWORKS API<\/a> and I keep a list of all available ID types in All identifiers and IDs in the SOLIDWORKS API<\/a>.<\/p>\n
              Names of features, faces and edges are great, but users can often change them. So we need an ID that stays the same, that is\u00a0persistent<\/em>. That’s when the Persistent ID comes into play. It consists of an array of bytes (so numbers of zero to 255) with a length of 16 (sometimes), 20 (often) or way more, like 491 bytes (occasionally). An example:<\/p>\n
              176-054-000-000-003-000-000-000-255-254-255-000-000-000-000-255<\/p><\/blockquote>\n
              You can store the persistent ID in a variable so that you can retrieve that object again at a later time. You can’t trust it 100%, though. To quote myself from my blog post about IDs:<\/p>\n
              Each ID value is unique within a model and it generally stays the same, even across SOLIDWORKS sessions. There is a remark<\/a> in the docs, though, that it can change with rebuilds, but I don\u2019t remember that actually becoming a problem in my software.<\/p><\/blockquote>\n
              3. How to get an entity’s object<\/h3>\n