SW 2001+ to 2003 transition, specifically macros

[Jimijames]

Our company likes to wait for the 1st SP to come out until deploying new software so we are still on 2001+ (that's what the IS guys tell me anyways). Recently, I've had some free time so I've really started exploring macros/VBA. I don't anticipate any problems with the macros I've written so far, but I wanted to ask if anyone has had any problems with 2001+ macros not transitioning well to 2003.

thanks,
jim

 

[dsi]

The only problem I had was that I had to reconfigure the macro buttons. There is a new format in 2003 for assigning macros to buttons (now you can add your own bmp images). Although most of my applications are VB executables, they employ the same techniques as a VBA macro. One additional feature they added now lets you specify which subroutine to activate upon running the macro.
DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

 

[APPENG]

Jim,

as with any application, there are things that are added and other things that are antiquated.

when transitioning over to a new realease, sometimes, the commands (methods) are superseded with new one's this is usually not a big deal, but sometimes you need to go in and edit the macro and replace the old method with the new...

for the most part its a painless process.

hope that helps,
Regards,
Jon
jgbena@yahoo.com

 

[rocheey]

As far as *compatability* goes, there is not much difference if you are using late binding, and just optimizations, if you are using early binding.

There are of course, the usual 'obsoleted' methods (replaced with a higher numeric count), such as "Entity.Select2" is replaced with "Entity.Select3",

the "AssemblyDoc.ReplaceComponents" call now requires a different call altogether, as well as the Block Definitions calls (but I think they are much better)

When you parse the feature manager tree, you will find 2 new
'features' ... Solid Bodies , and Surfaces. The Surfaces feature is hidden and I have been unable to 'unhide' it.

These are both in respect to the ability SW now gives for 'multi-lump' bodies.. (like floating pieces of solids)
If you find more than one 'solid body' while parsing the feature manager, the model may not be completed, or it may have errors.

And if you usually rely on fancy Equations/design tables to
harness in your configurations, you may find the "Macro Feature" a pleasant suprise.

 

[mpinder]

Yes, we have had problems with our custom property macro.
Before we upgraded to SolidWorks 2003, our custom property
worked fine. Now we can't get it to run. Every time we try
to run it, we get a run-time error. Does anybody know of any custom property macros that work with SW 2003 and will allow you to input multiple lines of text into a single property?

 

[dsi]

mpinder:
Have you tried debugging the macro to find out exactly which line is failing? The one I wrote a few years back has worked on every new release without an issue. Was it written in VB or as a SW macro? DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

 

[macPT]

As far as I know, SW allways try to make API backwards compatible. That means that, even if you have an obsolete function in your macro, SW performs OK because it still remembers how to proceed. The problem using obsolete functions is that you're not using all the power in the API.
I don't know if there's a garantee that it's allways like this in all functions.

Like dsi, I have obsolete macros running OK.

But I found 2 problems (not SW API problems) that you should pay attention:

- the VBA from different Excel versions (I use it for creting BOM's) are not 100% backwards compatible and you can have errors if you share Excel macros of different Office versions

- does your macro create previously the objects? If not, you should edit the macro, go to Tools/References and check the box for Solidworks type Library, in order to VBA recognize SW objects not created by the macro.

Hope that helps.

Regards

 

[Jimijames]

This may be a little off topic but, regarding mpinder's problem: I've seen similar behavior under different circumstances. One of our users had to have her PC rebuilt (win2k with SW2001+) and after that the custom prop macro I wrote would not launch. It would generate a runtime error...I traced it to the early binding, but only on her pc. For some reason, even though the SW type library was checked off under references, it did not like the [tt]Dim swApp as sldworks.sldworks[/tt] statement. Once I changed it back to [tt]Dim swApp as object[/tt], everything ran fine. I don't like it but it works. Anybody have any idea why this happened?

mpinder, hit the debug button as dsi suggested and that will give you a good idea where to start.

 

[dsi]

JimJames:

That's just fantastic!!! I have a feeling that it is not SW at all. We had a couple of machines that had this problem with an Excel VBA program I wrote. The only problem was the early binding declarations, and was specific to the two machines. I changed the Dim ws As Worksheet to Dim ws As Object and it worked perfectly. I spent a ton of time trying to determine the cause to no avail. Strange thing is that these machines are NT / Excel97. Needless to say, I changed to late binding and gave up... DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

 

[macPT]

JimiJames, dsi,

This is the problem that I reported in my earlier post.

If the macro as declarations like "Dim swApp as sldworks.sldworks" and not expected declararions like "Dim swapp as Object", that means that the object is not created an the VBA needs to be referenced to Solidworks Type Library (I am not an VBA expert but I think that, when you link that library, VBA knows, by default, the SW objects - you don't need to create them in the code).

Otherwise you must edit the macro and change all declarations of the type "Dim object As something strange" by "Dim object As Object" in order to previously create the objects. I have done this in some macros until I found that I could simply check the box for linking the SW library for reference.

Regards

 

[dsi]

macPT:

Although the behavior is the same, this is being caused by something else. You are correct, you need to add the Object Library for early binding. These errors were occurring even when the correct object libary was added to the project. DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.