VB API question

What's your code look like? Chances are you are either opening 400+ models (and not closing them), or something similar. My batch convert program suffered the same fate the first time I tried to convert a few hundred files because I wasn't closing each document after I was done with it (using .QuitDoc()).

dont active the doc. use copmpont2 getmodeldoc. that way the screen will never change from the assembly

that works great for assemblies, I use it myself. But for parts and drawings, this doesnt work. Too many API commands rely on using the active doc/sheet/etc...

Thanks guys, as rocheey pointed out I need this for parts. Let me make myself a tad clearer. I may have an assembly in memory, I may not. I need to walk all parts (ignoring all other objects) and access the custom properties (add/delete) without making the document the active doc. Its really a shame if I cannot do this because I will be forced to do this outside of SW i.e DSO File.

Hi try using dim swmodel as modeldoc2,nextdoc as modeldoc2 swmodel= SldWorks.GetFirstDocument ( )

and then nextDoc = swmodel.GetNext ( ) then you can use the custom properties functions

regards Dudi Peer ECI

Got it folks! Thanks for the assistance, I took the stupid pill on Saturday, it took today to wear off!

Guy

show me your code and ill solve your problem

with dsofile.dll you can access only the standard windows properties (author, date...). If you need only those properties, use DSO, it is very quick since it doesn't load the file completely in memory. If you need to acees the SolidWorks & configuration specific properties, you must have the document LOADED in SolidWorks, which means it doesn't have to be ACTIVE (i.e). The simplest way to make sure all part documents are loaded is to "Resolve" any lightweight component. Check Component2::SetSuppression to do this in API. Then you can use Component2::GetModelDoc to access the model doc and its properties, the document will remain invisible, unactivated, but loaded.

Correct. It's fairly straightforward, as well.

Incorrect. It is possible, but it wont be done with a simple drag-and-drop of a custom control.

If one were to imagine the 3rd party storage as a disk file, then dsofile lets you look at the files in the root directory only. There are other .tlbs out there that will give you the 'folder names' of the subdirectories, if you will.

You'd then have to reverse enginner the stream format. I have done such a thing myself, and use it daily. While I cant post the code cause it was a 'work for hire', Id be more than happy to talk (?) someone thru how to do it, parszing the "CMgr" and "CMgr2" streams, which is where the config-specific information is held in the storage.

Isn't the structure of this portion of storage subject to change from one release of SW to the next? I was fearful of depending on these streams to "stay put" for the config property access. Perhaps this was an unjustified concern?

--Brenda

----------------------------------------------- Brenda D. Bosley, PE CustomSolids

Then I missed a point... I thought Guy was asking how to access SolidWorks custom properties, i.e. those you access through ModelDoc::CustomInfo and related SW APIs. AFAIK, those "custom properties" have nothing to do with the MS DSO thing, nor with "third party storage", they are SW objects stored in the stream. I maintain that loading the document is the only practical solution...

Actually the dsofile.dll can access the file-level custom properties as well as summary info. The configuration info is more elusive apart from access thru SW. I am intrigued at the prospect of quick-access to these properties as well, provided the methodology is fairly robust.

-- Brenda

----------------------------------------------- Brenda D. Bosley CustomSolids

Philippe,

Your assumption was correct in that I need to access the custom properties and configuration specific properties. However my problem still lies in getting new custom properties defined into the object without actually using the call Set Part = swApp.ActivateDoc(theName) in other words not making the the object the window with focus in SW as the following code will do.

Set Part = swApp.ActivateDoc(theName) Set Part = swApp.ActiveDoc()

Now do modify props as needed

swApp.CloseDoc swPathName

I am trying to avoid bringing the object to focus in SW, in other words writing to it as it sits in memory without making it the front most window. I am probably missing a subtle call somewhere. Keep in mind the object is already loaded in memory as its in the assembly that is/was the focused window in SW when start walking the tree with a recursive routine that contains the above call.

Thoughts?

get modeldoc from component2

Correct. But as I said in a previous post, you must make sure the component is resolved. Attempting to get the ModelDoc of a lightweight Component directly will fail:

Yes, it may, and it has a few times. Of course, the Solidworks API in general has obsoleted many a well-used command. (remember ModelDoc?)

But as far as the stream goes, once you are in the stream, there are btye markers that can help you step thru the field lengths. Ive looked back a few years at differing .sldprt files, with a close eye on the CfgManager stream, and there has been one major change; the change of the stream name itself, from "CMgr" to "CMgr2", which coincided with the implementation of the 'derived configurations' feature, and another major/minor change, with the addition of the "Alternate name in BOM' feature. SW04 now seems to have also taken (most of the) unicode strings out in English Language installs.

rocheey,

I think you mentioned earlier that there were other tlb's that you were able to use to see the structure of the storage area. Are these readily available to Visual Studios or .NET developers? Would you mind sharing their names?

Thanks, Brenda

----------------------------------------------- Brenda D. Bosley, PE CustomSolids

Philippe,

Could I trouble you to post a little snippet of code for the Component2.GetModelDoc in the context of I already have the file name I need to address. i.e.

Set ....? retval = Component2.GetModelDoc () => Do I pass in the name here? modify properties, etc.

Thanks for the assistance.

I believe you would have to do it like this

Dim RefModelDoc as ModelDoc2

Set RefModelDoc = Component2.GetModelDoc

Where the Object Component2 is already set to an opened component.

Regards Corey