Unfortunately SW macros have references to version specific libraries. These may need to be updated manually. To do so, open your macros in the editor, and go to Tools -> References. References to 2010 versions will be marked as missing or something like that. If there are broken ones, deselect them and select the corresponding 2011 files.
I just think it's interesting that I've been using these macros for years, and I just had a problem with this upgrade. That's why I assumed it was a 32 to 64 bit problem.
I'm sure I remember some macros being posted (either here or at the forums.solidworks.com site) where the authors claimed the code had been modified to run on any version of SW. However, I have no idea what that coding mod' involved.
Sometimes it becomes impossible to keep old libraries alive, and thus, new ones need to be created.
IModelDoc was outdated, or couldn't do whatever the SW devs needed. So they took the functionality in it and made...
IModelDoc2 which included a lot of new functionality.
Eend
Thanks for the tip.
I got macros to work but I notice the status messages I had inserted to let me know when the macro is complete do not pop up in graphics area. I do however get the notification in the toolbar. If I click on it, my message appears in window. Any ideas?
One possible reason for not encountering this issue in the past, then encountering it now could be switching of computers, or maybe doing a full uninstall/reinstall... I'm not sure exactly what would delete the old libraries off an existing machine, but if you get a new machine at the same time as upgrading SW, you will likely get the "Object or library not found" errors.
The "version independent" macros use what I think is called "late binding". I'm sure someone with actual training or education could give a more full explanation, but basically there are two ways to work with object variables in VB/VBA/etc.
The first way is to declare everything as an Object, like
Dim Part As Object
An object in VBA is very general. Could be almost anything. Just about everything useful in the SW API is a particular type of object. Then, when you load that variable later, like
Set Part = swApp.ActiveDoc
VB/A has to figure out exactly what it has. And when you use that variable, like
MsgBox Part.GetType
VBA has to go look at the thing it's got that's called "Part" and see if it can do "GetType" or not. If it can't, you get a runtime error, because the error occurred while the macro is processing. VBA has no way to know if "GetType" is a valid method of "Part" until the code is actually running. If you use this style of programming and this kind of error occurs, your system/part/code/whatever might be in the middle of something and the user won't know what has happened. For example, maybe in your code you turn some options off in SW to make the macro run faster, then you turn them back on later in the code. A runtime error will stop the code execution in the middle, so those options don't get turned back on. The advantage of this style of programming is that you don't have to include references to any libraries, so you don't get compile errors.
Or you can use "early binding" and tell the code what specific kind of object that "Part" is going to be, like
Dim Part As SldWorks.ModelDoc2
This tells VBA that whenever you load the variable with
Set Part = swApp.ActiveDoc
that it should expect a specific type of object called a ModelDoc2. It knows what a ModelDoc2 should look like because there's a definition of it in the library called SldWorks. Of course, VBA has to know where that library is so it can look in it. If VBA doesn't know where that library is, you get that the "Object or library not found". You tell VBA where to find that library under Tools->References.
So what's the difference now? Well, now VBA knows exactly what "Part" should look like when it gets it. It also knows ahead of time (before code starts executing) what sorts of things "Part" should be able to do. So if you try:
MsgBox Part.KissMyButt
VBA will give you a compile error before the code starts executing. The other advantage is that while you are writing the macro in the VBA editor, you get IntelliSense... basically some live realtime feedback. So when you type "Part." you get a little dropdown box right there that has all the available methods and properties of the ModelDoc2. If you use late binding, the code editor has no way to know what kind of thing "Part" will be, so it can't give you that help.
SolidWorks updates the API with every release. They add new stuff, but old stuff all works the same. If you use late binding, and you only use old methods and properties, your macro will likely work on any machine in any version of SW without issues. That's how the "version independent" ISO macro that CBL linked to works. However, stating that it will work with all versions of SW is slightly inaccurate. It uses the method "ShowNamedView2". When SW runs the macro, it will look at the thing it has that was named "Part" and sees if it can do "ShowNamedView2". However, "ShowNamedView2" was added to the API with SW 2001Plus. So if you are running SW 2000 you will get a runtime (not compile) error.
Oh, and Dan, I'm still around. But I've been awful busy lately. And not using SW either. Oddly enough, the year I finally make it to SW World is also the year I'm transitioning from mechanical design engineer and office SW guru to more of a supervisory role. It's a weird transition. You spend eight or so years trying to learn how to be the best engineer you can, then you get to learn a new job.
I ran into the same thing and had to rewrite a bunch of code. There have been lots of little changes. One that I ran into was getting and setting options.
handleman
<from mechanical design engineer and office SW guru to more of a supervisory role>
Congratulations - if you pick up on this new role as well as you did SW VBA, I'm sure you will be very good at it.
As I was reading this, I was thinking the same thing as fcsuper.
Attached is the code I've been using. Not sure about using it in 2011 though.
