After nearly two years at 3DVision I am being released into the CAD blogosphere. Management was wary but finally caved. Jeff Sweeney is jealous that he no longer has a monopoly over the API category. Diversity is good, however, and so as to distinguish myself from him and rest of the 3DVision tribe I will mostly focus on SolidWorks administration, installation, and performance troubleshooting, with the occasional API post thrown in for seasoning. I can hear you adding this to your RSS feeds already!
Let’s kick things off with the API. As you know, or as the weird guy a couple cubes over has insisted, the SolidWorks API is pretty cool. Balancing out this coolness, unfortunately, are some very peculiar headaches. Perhaps the most common of these headaches is the sudden “Compile error” warnings you might get when running a macro that caused you no trouble in the past. Out of the blue, this is what you might see:

Other variations might include “Object library feature not supported”. What is particularly strange is that the problematic code is often times something as innocuous as a string manipulation function, such as Left(). Otherwise the problem is probably with the first line of your main sub-procedure: “Set swApp = Application.SldWorks”.
Though this can arise out of the blue, sometimes the error occurs when you upgrade to a new operating system (e.g., Win XP to Win 7). Regardless, the cause is the same: the macro has “lost touch” with its references. Why? I would probably have to crawl around MSDN knowledge base articles to find that out, something I am averse to doing. The solution, however is simple: reset the references. One way to do this, while in the VBA IDE is to go to Tools–>References, and uncheck any SolidWorks-related references, click OK, re-open the References, re-check those same references, and click OK. (Sometimes you might also see a reference with “MISSING” in front of it, which can simply be unchecked.)

If this still fails, the issue might be with one of the primary VBA libraries that you cannot uncheck while in the macro (you’ll get a “Can’t remove control or reference; in use” warning). In this case, you will need to create a brand new macro and copy and paste your code from your old macro into this new one. This is the foolproof solution, but can be tedious if you need to move forms as well.
Bonus: on Windows x64 there is another “bug” that is equally frustrating. If your VBA macro has forms that pop up during the execution, fair chance that they will pop up BEHIND the SolidWorks application, leaving the end user scratching his head as to why SolidWorks suddenly froze. But it did not freeze at all! Simply hit Alt+Tab and scroll through the available windows until you find this form. S-013887 in the SolidWorks knowledge base includes code that can be added to your macro to fix this, however, in my experience, adding the extra code is tedious and adds enough complexity to your code that you might as well get used to Alt+Tab on less-used macros.
Happy coding,
|

|
Keith Rice, CSWP
Application Support Engineer
3DVision Technologies |