"Corey Scheich" <email@example.com> schrieb im
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 > )
> Did you know that you can reference the swconst.tlb you no longer need to
> use the bloated .bas file in 2004
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
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.
> That makes alot of sence, but wouldn't you still run into
> trouble since the constants you are entering into your macro
> are the ones that were "Tailored" if you will, for the
> current release.
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.
> If these had changed wouldn't you still run
> into trouble on major release changes. Obviously you will
> not have backward compatibility with the .tlb but wouldn't it
> help with forward compatibility.
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" ;-))
> I personally am currently
> adopting the cut and paste method of only using what I need
> from the swconst.bas, but we haven't upgraded to 2004 yet.
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).
> It probably would have saved a bit of trouble if they would have
> implemented that years ago. I guess it is possible to have
> an initializing
> module that would load a set of cut/paste constants if 2003
> was running and another if 2004 was running. Or just have one
> bloated version for each major release. I don't really know.
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.
unofficial german SolidWorks helpsite
tools and programs for SolidWorks