FYI - swconst.bas for SolidWorks 2004

FYI - swconst.bas for SolidWorks 2004
For all of you, who prefer to use constant declarations in their macros and tools to avoid problems with the
typelibrary when switching between major versions of SolidWorks I offer my selfmade swconst.bas file for SolidWorks 2004 at http://swtools.cad.de/macros.htm
It's the one labeled mm_998.zip. The download includes my latest constants file and the DIFF-files for previous servicepacks.
Hope you enjoy this, any feedback it very welcome.
Bye, Stefan
--
unofficial german SolidWorks helpsite
http://solidworks.cad.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I thought it was no longer necessary to include constant declaration (or import the swconst.bas) with VBA's in SW2004?
Ken
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
It isn't I believe he is doing this more for backward compatibility.
Corey Scheich

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Did you know that you can reference the swconst.tlb you no longer need to use the bloated .bas file in 2004
Corey Scheich

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Newsbeitrag
Corey mailed me (accidentially) about this, but we think this should be posted here also. Here are the major parts of our mail discussion (Coreys are shown with the > )

Yes, I know, but that's exactly the point why I made the swconst.bas myself. You say, I CAN use the swconst.tlb ... that's not quiet correct, I HAVE TO use it, if I don't take the time and declare the needed constants by hand.
So why I don't like to use the swconst.tlb? As you can see, I offer many macro at my webistes http://swtools.cad.de and http://solidworks.cad.de for free, and I prefer to write my macros the way that most people can use them, even if the don't use the most up-to-date version of SolidWorks.
If I would use the swconst.tlb it would be easy for all, who uses SW2004, but for the other ones (including the company where I'm administrator ;-) I would have to say : "Sorry, I'm to lazy to declare the constants, upgrade your SolidWorks"
No, not the way I choose. BTW, that's the same reason why I don't use the other typelibrarys which would allow early binding, this brings so much trouble with different major versions of SolidWorks.
But you're right, I (personally) would also say "bloaded .bas"; on the other hand I never add the complete bas-module, but opens it in an editor and copy the lines I need in my macros or tools.
I hope you understand why I made this module (at least for myself); now that I made it, it was only a little step to put it on my website.

Yes, and no. You are right, if you want the backward compatibility you have to check the constants, whether they are new or not. But you have to check this with the TLBs also. Example are the constants new to SW2004 SP1.0, if you use the TLB and doesn't care about that you may end up with a macro which works for you (if you are using SW2004 SP1.0 or above), but wont work for the guys in the shop, if they still use SW2004 SP0.0
So no advantage or disadvantage with this point for either method.

That's the major pitty, it doubt it will help with forward compatibility. Say you have installed SW2004 and there's the reference to swconst.tlb In your registry, there have to be a path to the TLB, so let's assume the reference points to c:\program files\sw2004\swconst.tlb
Now you install that famous SW2005 ;-) and you don't deinstall your productive SW2004 yet; you wouldn't do that, would you???
So where would you expect the reference for the swconst.tlb to point to? To the one in folder SW2004 or in SW2005? And what will happen if you deinstall one or the other? According to Murphy you are left with a reference pointing to nowhere ...
So may be SolidWorks will change it and make a reference to each major version constants file, as they do it now with the SolidWorks TypeLib. This wouldn't help either, for then you will have a macro written in SW2004 which points to swconst.tlb of SW2004 ... you can open this on any machine, where swconst.tlb of SW2004 is installed, but for these "new" customers or the ones which choose to deinstall SW2004 the macro wont run. Okay, you can easily change it by editing the reference to the new typelibrary ... but if you tried to support other users (even in foreign countries) it's not that easy to have an idea what's going on with the macro, for the error codes are more than confusing if you ran into this kind of problem (and yes, I had a few of these "challenges" ;-))

As said, I prefer this method, for everything lays in my hands and I know exactly, what kind of constants are there and not and what kind of references I use (I prefer as little as possible).

Well, I think the best is to take it the way it is the easiest for everyone himself. If I would do this only for me or the company I'm working for I wouldn't mind and take the references, for it is much less work to do. But for the other guys (like me ;-) may be they will stay with the tested, easy and stable method of cut/paste the constants now that they have them ;-)
-- end mail discussion
The basic idea behind this was to have a file with all the constant declaration to easily cut/paste them where necessary.
Bye, Stefan
--
unofficial german SolidWorks helpsite
http://solidworks.cad.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.