Tick Talk on EsoxRepublic.com


Esox “Copy Custom Info” revived and updated guts

Posted in API, Esox Software, Software by Administrator on the May 1st, 2010

You just never know how popular some things are until they break.  This apparently is true for my “Copy Custom Info” macro.  The macro seems to have stopped working for many SW 2010 users.

The macro is ancient, by API standards.  It is one of my first published macros, and was written in SW2003.  Judging by the code, I wrote it before I was aware of early binding.  Also, SW’s API has come a long way and there were many ways to streamline the code.

I was able to do away with much embarrassing sophomoric hacksmanship. Glad to get that behind me.  Most notable improvement is that the program no longer needs to make duplicates of the files it is copying from (do not judge, I had my reasons!).  Assemblies and drawings selected for copying will open much faster.

The interface is about the same.  The only visible improvement will be in the preview windows.  There will be some indication that this is the SW2009 version.

The program will be posted on EsoxRepublic.com in the coming week.  Notices to be placed in popular forums that your less-popular author frequents.

Shapeshifting Through SW Dimension API

Posted in API by Administrator on the October 21st, 2008

One of the sticky things about working with SolidWorks API is the fragmented object structure. Often, it takes more than one object type to deal with a single object. The most common example is the ModelDoc/PartDoc/AssemblyDoc/DrawingDoc objects. All SW files are ModelDocs, but many API functions are only available in the type-specific objects, and accessing those functions may require setting a second PartDoc or AssemblyDoc or DrawingDoc object after the ModelDoc object is already set.

A less common but more convoluted set of objects is the ones that deal with dimensions. There are as many as four different objects that deal with a SolidWorks dimension:

  • Dimension: Properties and methods for the dimension parameter, such as name, value, driven state
  • Tolerance: A sub-object of Dimension, used to access tolerance info
  • Display Dimension: Dimesnions can be displayed in more than one place, DisplayDimension is a single display instance.
  • Annotation: DisplayDimension is a sub-object of the Annotation object. You would need the Annotation object to access layers and leaders.
Dimension object chart
Hierarchy of dimension-related objects.

Selecting Dimensions

When Accessing selected dimensions, the SW SelectionMgr object passes selected dimensions as DisplayDimension object. This means that it is necessary to pass the DisplayDimension object to a Dimension object to change its value. It would be necessary to pass the DisplayDimension to an Annotation object to change its layer. To change a tolerance, one may need to access the Tolerance object (though there are some unlisted Dimension object API’s that access tolerance data).

The example code below shows how to take a DisplayDimension from the SelectionMgr, pass it to a Dimension object, and then change the dimension value.

Set swApp = Application.SldWorks
Dim swApp As SldWorks.SldWorks
Dim ActDoc As SldWorks.ModelDoc2
Dim SelMgr As SldWorks.SelectionMgr
Dim DispDim As SldWorks.DisplayDimension
Dim DimToEdit As SldWorks.Dimension

Set ActDoc = swApp.ActiveDoc
Set SelMgr = ActDoc.SelectionManager

‘get selected DisplayDimension object
Set DispDim = SelMgr.GetSelectedObject6(1)
‘pass selection to a Dimension object
Set DimToEdit = DispDim.GetDimension
change value of Dimension object
DimToEdit.SetUserValueIn2 ActDoc, CDbl(2.78), swSetValue_UseCurrentSetting

OT: Football pool

Once again, I’m in a football pool. Once again, I was off to an abysmal start, 4-5 right per week. Until last week, that is. I changed my pick strategy. For the last two weeks, I have picked the team whose home city has the highest crime rate. Got 10 right last week and 7 this week (our winner only had 9). I’ll go with this strategy for a while longer and see how it pans out.

“ShellExecute” to Open a File in Its Default App

Posted in API by Administrator on the September 26th, 2008

To introduce using Windows API in macros, I picked the simplest example I have in my toolbox: opening a file in its default application. Using the ShellExecute command, one can call a file to simply open in its default application, much the same way that double-clicking a file icon in an explorer window would do. I use it to add hyperlinks to my website in my published macros.

The “Declare” Statement

To use a Windows API function in a SolidWorks macro, one must first add the function to the macro code using a Declare statement. A declare statement acceesses and names a function in a Windows DLL library for use in VB code. Elements of a Declare statement are thus:

  • Name of function or sub
  • “Lib: name of DLL library containing function or sub
  • “Alias”: a user-defined alternate name for the function
  • function parameters
  • Return variable

An example of the declare statement for ShellExecute would look like this:

Public Declare Function ShellExecute
Lib “shell32.dll” _
Alias “ShellExecuteA”
(ByVal hwnd As Long, _
ByVal lpOperation As String, _
ByVal lpFile As String, _
ByVal lpParameters As String, _
ByVal lpDirectory As String, _
ByVal nShowCmd As Long) _
As Long

Using ShellExecute for Hyperlink

To make a hyperlink, I use ShellExecute to open a web page. The user’s operating system determines the default application with which to open the web page.

Public Sub OpenEsoxWeb()
ShellExecute 0, vbNullString, “http://www.EsoxRepublic.com”, vbNullString, “C:\”, SW_SHOWNORMAL
End Sub

Connect the OpenEsoxWeb sub to an object in a form to give that object a “hyperlink”.

Private Sub lblWebLink_Click()
OpenEsoxWeb
End Sub

You can find an implementation of this in my Delete Custom Info macro.

Works with any file

Use ShellExecute with any file you want to open: web pages, MS Word, Excel, or PowerPoint Docs, images. Wherever you need the effect of a “double-click”.

Links:
AllAPI.net archive on Mentalis.org
The Borg

Thought for the day

The two best things to bring to a gunfight: a gun, and a friend with a gun.

SW BOM to Excel Macro

Posted in API, Esox Software by Administrator on the September 11th, 2008

…not quite, but a fast way from here to there.

I just released a macro I have been using for a few months. “Copy BOM to Clipboard” macro does exactly what it says: it copies a table-style BOM from a SW drawing to the clipboard in a format that can readily be pasted into MS Excel. Download here.

Just run the macro with a SW drawing open. If successful, there will be a message like that shown below. Then go to an Excel worksheet, select a cell, and paste (”ctrl-v”).

BOM to Clipboard message window
Message box indicating successful acquisition of BOM.

Developer’s notes

It’s been a while, but I am trying to remember some of the specific challenges of writing this. It took about two hours of fumbling until the error-to-trial ratio dropped below 1.0.

Application writing is often mostly about validation. Checking to see if there is an active document, is it a drawing, does it have a BOM (or more than one). That took most of the time.

There was a hook to getting ahold of the table data. I put the BOM data first into a SldWorks.BomTableAnnotation object, then moved it to a SldWorks.TableAnnotation object which could then be parsed into an array. The final array is then written to a tab-delimited string which pastes so nicely into Excel.

It could have been more elegant, but it “works fine, lasts long time”.

Thought for the day

Speak softly and carry a big stick. Some folks out there can take a punch much better than they can take an insult.

AllAPI lives

Posted in API by Administrator on the August 29th, 2008

Long live AllAPI.

Yesterday I reported that AllAPI.net was gone. The domain is gone, but the site lives on. It has moved to http://allapi.mentalis.org/. This is my go-to site for Windows API snippets.

Also recommended: codetoad.com. My registry utilities VBA code module came from here.

In upcoming weeks, I will be discussing using Windows API to enhance VBA macros with functions like

  • “Save” and “Open” dialogs
  • Folder browsing dialogs
  • File security
  • Registry tools

R.I.P. AllAPI.net

Posted in API, Uncategorized by Administrator on the August 28th, 2008

I was gearing up for a set of articles on using Windows API in macros. I was going to lead off with a brief article about one of my favorite resources, AllAPI.net. Unfortunately, that article has turned into an obituary.

For years, AllAPI.net was my first stop for Windows API help. I first discovered it in 2003. Already, the site had been relegated to archive status, available but no longer updated. Still, it was an indispensible resource for adding Windows API functions to code.

I’m verklempt. I’m lost. I don’t know where to go, now. If anyone has links to good online Windows API examples, I would appreciate a heads-up!

Windows API to extend macro functionality

Often, questions come up about adding certain functions to a SolidWorks macro. File open/save and folder browsing are the most popular. Since the dialog objects for these tasks are not licensed to VBA, one must take a backdoor approach via Windows API. I also use Windows API for Windows file security, registry functions, and opening documents.

Early Binding Speeds API Programming

Posted in API by Administrator on the July 24th, 2008

One of the challenges when writing API code is keeping track of objects and their methods and properties. Early binding can help with that.

“Early binding” simply refers to the way that object variables are defined. Instead of defining an object variable with “Dim swApp as Object”, define it as the specific object type, i.e. “Dim swApp as SldWorks.SldWorks”.

Here is what SW gives you when you record a macro:

Dim swApp As Object
Dim Part As Object
Dim SelMgr As Object
Dim boolstatus As Boolean
Dim longstatus As Long, longwarnings As Long
Dim Feature As Object

This is what the same code would look like adjusted for early binding:

Dim swApp As SldWorks.SldWorks
Dim Part As SldWorks.ModelDoc2
Dim SelMgr As SelectionMgr
Dim boolstatus As Boolean
Dim longstatus As Long, longwarnings As Long
Dim Feature As SldWorks.Feature

Ctrl+J and Intellisense

One of the handy features in the VBA editor (macro editor) is a list of available commands that pops up when typing, known as “intellisense”. Details can be found in the VBA help under “List Properties/Methods Command (Edit Menu)”. With intellisense, there is no need to commit an endless list of commands, objects, methods and properties to memory. It’s all right there.

Screenshot of Intellisense drop-down list
Screen shot of intellisense Pop-up drop-down menu. Menu pops up after typing “.” after a valid object name or “ctrl+J”

Intellisense pops up immediately when one types a period following the name of an existing object. But, there’s a catch: if the object is defined with a Dim statement using “As Object” instead of as a specific type, it is not available.

Also, intellisense is available to add commands and objects by pressing ctrl+J.

The other advantage to early binding comes when a program is run. Early binding decreases the time it takes to set an object. Not a big deal for small macros, but it could add up for larger program.

Comparing files’ internal ID’s

Posted in Internal ID by Administrator on the May 22nd, 2008

Originally posted on the SW website API forum, forums.solidworks.com
Compare file internal ID’s

There is no way in SW API to get a document’s internal ID (”IID”). SW doesn’t make that data publicly available, apparently because it would be too convenient for programmers who need that information. Still, there is a way to divine some useful information about a file’s internal ID.

SW recognizes two files as having the same IID if
1.) they were created at the exact same second
2.) they were created by the same installation of SW

Very difficult to ascertain #2, but #1 comes easy.

To answer the question, “Do these two files have the same internal ID?”, one need only check the creation date. But, not just any creation date. There are many ways to check creation date, and most will not work for this purpose. The creation date of interest is the one generated the instant a user clicked the final “OK” when creating a new file in SW. What’s the right way? Use DSOfile.dll. The property “SummaryProperties.DateCreated” records the moment SW brought this file into being. It does not change when a SW file is moved, renamed, or copied. It is the “mitochondrial DNA” date stamp, passed down intact through generations of saves, moves, and copies.

What’s the wrong way? Nearly any other creation date property or method. SW’s custom property “SW-Created Date” can change due to a Save As operation. Windows API methods creation dates can change depending on how and where a file is moved or copied.

How reliable is the DSOfile create date for determining if two files share an IID? The inverse of the probability that two files of interest were created by two separate people at the exact same second. Good enough.

Things API teaches about SW

Posted in API, Internal ID by Administrator on the May 21st, 2008

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