Interesting question. Your suggested solution is the only reasonable solution I'm aware of right now but I'll be interested to see the other responses this thread generates.
The reason the error occurs in the first place is because a macro remains loaded in swvbaserver.exe even after it is finished running. So technically you could programmatically kill this process if you wanted using this code:
Shell "TASKKILL /F /IM swvbaserver.exe", vbHide
The problem is that, for whatever reason, macros can no longer run during that SolidWorks session. Swvbaserver.exe won't re-execute if you try to re-run that macro or any other. SolidWorks has to be restarted.
VBA's built-in Unload statement also yields no fruit, as far as I can tell.
I could not find a way to get SW to release the macro. I used the MacroLaunch macro at Lenny’s website for a time. It uses an ini file where you enter the path of the macro you want to run. When I updated a macro I named them MacA, MacB, etc and just changed the name of the path in the ini file.
I have all of our macros on the network. I have since written my own program but this one worked quite well.
You will need to change the reference from 2006 to 2013:-)
This is almost exactly what I am doing in my company.
I have a text file where the version is stored, so I am always working on one version above everyone else's.
When I want to push an update, I point the .ini file path to my new one and I bump mine up as well.
This has been working quite well for some time now. Next step is to put that ini file's data into a database so that it can be controlled a little bit more elegantly.
I had some slack time a year or two back and wrote an exe program based on Lenny’s program. It is ini driven. The program detects the file types and opens it in VBA if it is a swp file or a standard windows program if it is an Excel, word or another standard file type. Because of this the list also includes information files. I also added icons so it is a bit fancier than I normally get. It does require a swp file to start the exe and this is added to everyone’s tool bar through the menu bar. After the program is started the entire list of information and programs is available to the engineers without loading it to thier drive. I find it easier to manage the information on the network. This was a fun project to do because there were no time lines or constraints on how it had to work.
SW 2013 SP03
I keep all the macros on a server but then use task manager to run a robocopy script to copy them local every time the user logs in. i drop them right into c:/program files/solidworks/macros so i can set key shortcuts on some. works great, and i do something similar for toolbox files and templates and such. So much easier than trying to hunt down the first person who launched a macro.
Hi Cory, I just received this SPR today. Contact your reseller to get added. I don't see it in the KB just yet, but should show up within a couple days.
SPR740727: "Shared network use of a macro is limiting multiple users as the macro does not unload after running it"