Tick Talk on EsoxRepublic.com

Part 1 of ?

One of the things I like about learning the API of SW is that it gives great insight into what is going on deep inside SW. The insight is not limited to just the SW application, either. I believe that the API also reveals some of the goings-on at the SW development offices.

Internal confusion about Internal ID

It’s a subject that has come up many times, in many places. API programmers working with SW drawings and assemblies need access to the internal ID (”IID”) of SW files. Without fail, they fail to find an answer. The answer I got from SW API support was in two parts:

1. “SW API does not give access to IID information.”
2. “You shouldn’t need it. If you needed it we would have given it to you.”

But we do need it. It comes up quite often, for many reasons. It is needed when swapping references. It is needed when attempting to repair lost references. It is needed when (re)organizing a non-PDM-using company’s SW file pile.

Access to IID data is a basic (if not primal) requirement for managing references. Yet, SW has done nothing to open it up to public API users. SW won’t even acknowledge its importance. Version after version is released without any tools for even comparing file IID’s. This clearly is a case where SW is 180° out of phase with the want and needs of the API user.

A partial solution exists

Recently, I posted a partial solution to the IID problem in forum.solidworks.com. Once I track it down, I will repost it here. There is a method to retrieve creation date information of a file which provides a means of reliably comparing SW file IID’s.

Coming soon

1. A solution for comparing file IID’s
2. Lost in lofts at SW