VB API question

Is there a way to access (delete & add) the custom properties of an
object which is memory (in SW) without actually making the object
active doc, i.e.
Set Part = swApp.ActivateDoc(ObjectName)?
The problem I am running into is in very large assemblies (400+
discrete parts) I am seeing failures (SW Automation failures) as I
loop thru each objects (in this case I parse for parts only) using the
Set Part = NextDoc call. I am beginning to think it might be a memory
leak as performance/speed degrades the further into the loop I get.
Reply to
Guy Edkins
Loading thread data ...
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()).
Reply to
Markus Wankus
dont active the doc. use copmpont2 getmodeldoc. that way the screen will never change from the assembly
> Is there a way to access (delete & add) the custom properties of an > object which is memory (in SW) without actually making the object > active doc, i.e. > Set Part = swApp.ActivateDoc(ObjectName)? > > The problem I am running into is in very large assemblies (400+ > discrete parts) I am seeing failures (SW Automation failures) as I > loop thru each objects (in this case I parse for parts only) using the > Set Part = NextDoc call. I am beginning to think it might be a memory > leak as performance/speed degrades the further into the loop I get.
Reply to
Sean Phillips
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...
Reply to
rocheey
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.
Reply to
Guy Edkins
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
Reply to
david peer
Got it folks! Thanks for the assistance, I took the stupid pill on Saturday, it took today to wear off!
Guy
Reply to
Guy Edkins
show me your code and ill solve your problem
Reply to
Sean Phillips
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.
Reply to
Philippe Guglielmetti
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.
Reply to
rocheey
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
Reply to
Brenda D. Bosley
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...
Reply to
Philippe Guglielmetti
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 Guglielmetti" wrote in message >
Reply to
Brenda D. Bosley
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?
Reply to
Guy Edkins
get modeldoc from component2
Reply to
Sean Phillips
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:
Reply to
Philippe Guglielmetti
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.
Reply to
rocheey
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
Reply to
Brenda D. Bosley
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.
Reply to
Guy Edkins
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
Reply to
Corey Scheich

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.