Well, it works great, and I'm using it a lot, since it does what I was looking for from years: it calculates the quantities of parts in an assembly and writes it down into configuration-specific custom properties.

1) Here comes a subtle problem. It writes down the quantities in configuration-specific custom properties, but many of my drawings are already linked to general custom properties or to DefaultFlatPattern custom properties. How can I make it write the same property (AutoQty) into general custom properties too?

2) For large (100+ components) the cycle becomes really slow: is there a way to make it faster? I already made a modification, but it's not fast enough...

Are you using this macro as an equation or as a standalone macro? The way it is written is not particularly efficient. I wrote it to be simple and short code to fit into an equation. I must confess that I don't actually use it myself or I might have optimized it better. If you are using it as a standalone macro, it could probably be made considerably more efficient by using other methods or algorithms.

The change you made is good. It certainly increases efficiency.

To make it set general custom properties instead of configuration-specific, just replace Cfg with "" in each CustomInfo command.

Are you using this macro as an equation or as a standalone macro? The way it is written is not particularly efficient. I wrote it to be simple and short code to fit into an equation. I must confess that I don't actually use it myself or I might have optimized it better. If you are using it as a standalone macro, it could probably be made considerably more efficient by using other methods or algorithms.

The change you made is good. It certainly increases efficiency.

To make it set general custom properties instead of configuration-specific, just replace Cfg with "" in each CustomInfo command.

thank you so much for your answer, it just works! I'm really pleased you replied so quickly, I always read your posts and admire your programming skills. Thanks again.

About the macro.

We're using it extensively as a standalone macro, not as an equation. I really think the "equation trick" is great, and it should be seriously considered in some cases, but we're dealing with 500+ component assemblies, and it slows down the design process a lot, since it calculates at every rebuild...

We used to apply Lenny's "PropertyEditorGlobal" macro to propagate custom properties to all the components in the active directory, and it worked, but it doesn't calculate part quantities. Then I discovered your macro, modified it in many ways (adding some SendMsgToUser2, some controls here and there, basically to meet our factory habits), and began to use it in everyday work. It solved an old problem we had: insert the correct quantities in part drawings.

And it's true, the way it is written can be a problem for 1500+ components assemblies. In these cases, the execution of the macro can be really time-consuming (10+ mins). Maybe a traverse through the assembly could work, but here I stop, my programming skills are really poor.

For the line "Dim MyCmps", it could be declared as a Variant. Basically, with VBA if you declare a variable without specifying type, it's automatically a Variant. Variant is the correct data type to receive the array returned by GetComponents, so I skipped the type specification for code compactness. As I mentioned before, this was originally written to be packed into Custom Properties and executed as an equation, and the length of custom properties is limited. That's why there is no indenting either. That is also why I used the obsolete (but still supported!) CustomInfo2 calls instead of the newer CustomPropertyManager calls.

This whole macro could be prettified and expanded with some message boxes and a lot of different options for how it runs. However, that would take time I don't really have. Any volunteers? :-)

here you go. Export indented BOM (detailed numbering) from SW and then use code to calculate the amounts for structure. File includes just the basic stuff because I'm doing all kind of mods through the code and calculating the overall price for the main assembly among other things. For component amounts just add some code to sum the lines that have same component "code" or what ever you use to identify them.

I believe what is taking the longest is probably all of the calls to the SW API. All of the comparisons in the loop should just be string comparisons rather than multiple SW calls. This approach would be like:

1. Load a 2-column array with the path and referenced configuration name of each component, something like:

(this code is off-the-cuff, no debug)

dim CompArray(0,1) as string

for i = 0 to ubound(mycmps)

if (suppression state stuff) then

redim preserve comparray(i,1) as string

set mycmp = mycmps(i)

comparray(i,0) = mycmp.getmodeldoc.getpathname

comparray(i,1) = mycmp.referencedconfiguration

end if

next i

Now you have all the components in an array.

2. Create a new 3-column array. Iterate through CompArray and compare to the new array. If CompArray member is found in the new array, increment the quantity in the third column of the new array. If it's not found, add it to the end of the array with qty 1.

Now you have an array containing the full path, configuration name, and qty of each component.

3. Iterate through the new array. Use OpenDoc6 with appropriate option arguments to return a pointer to the ModelDoc2 of each element of the array and set the custom property.

In your case, you may want to add some code to check and make sure that you don't have two different configurations of the same SW file in the assembly since you are wanting to set general custom properties.

And it works, it gives me an array with the desired data. I was forced to define the static array dimension because "redim preserve comparray(i,1) as string" doesn't work. Redim Preserve lets you change the right side of an array...

And this becomes a problem for the definition of the new 3-dimensional array, right?

Hi, relatively new to solidworks here. I know this is an old thread, but man oh man it is exactly the topic I am looking for a solution for. I have this same macro that I pulled from another thread, these "AutoQTY" macros seem to be about the same from post to post on this forum. It works great, but I have one small issue. If I have mirrored parts in an assembly, I make those mirrored parts as a mirrored configuration in the same part file. I like to set up my BOMs as "display all configs of the same part as one item", because I consider a left hand and right hand set of parts to be only one part with quantity of 2, the shop can use the same drawing to make both, so, yeah. Mostly that's just the way we have always done it and I need to preserve it.

Problem is, the "AutoQTY" property seems to only count the configuration instances instead of the filename instances. So I may have a BOM read qty=2 and AutoQTY=1, because AutoQTY is only counting 1 in "Default"" and only 1 "MirrorDefault".

I just tried "To make it set general custom properties instead of configuration-specific, just replace Cfg with "" in each CustomInfo command"

as Josh Brady suggested in the first response above. I thought that may write the AutyQTY as 2 in custom properties tab of all configs since I don't think those are "configuration specific". That didn't work though.

So my solution so far is to set up my BOMs as "display configs of the same part as separate items". I don't like that, but it works to

If you want it to behave as "all configs of the same part are the same item", all you need to do is get rid of the configuration check. There are three "If" checks to see if this component should be added to the count:

If tCmp.GetSuppression <> 0 Then

If tCmp.GetModelDoc2 Is CmpDoc Then

If tCmp.ReferencedConfiguration = Cfg Then

cCnt = cCnt + 1

End If

End If

End If

All you need to do is comment out or delete the ReferencedConfiguration one, along with its "End If", like:

Any assembly may have multiple configurations. Different configurations may have different quantities of any given component. If the macro is run when the wrong assembly configuration is active, incorrect quantities may be written to the part custom properties.

To get the macro to run properly, you need to know the name of the assembly configuration for which you want to count quantities. Of course, if your assembly only has one configuration, it's probably named "Default". Whatever the name is should be put into the assembly's custom property named "Cfg4Qty". Then, if the active configuration name DOESN'T match Cfg4Qty, the macro exits and does not update quantities. If the name DOES match, the quantities will get updated.