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.

 

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

 

dont active the doc. use copmpont2 getmodeldoc. that way the screen

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.

 

with dsofile.dll you can access only the standard windows properties

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

 

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

 

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:

 

Isn't the structure of this portion of storage subject to change from one

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

 

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

 

Option Explicit

Sub TraverseComponent ( swComp As SldWorks.Component2, nLevel As Long )

Dim vChildComp As Variant

Dim swChildComp As SldWorks.Component2

Dim swCompConfig As SldWorks.Configuration

Dim sPadStr As String

Dim i As Long

dim CompModeldoc2 as modeldoc2


For i = 0 To nLevel - 1

sPadStr = sPadStr + " "

Next i



vChildComp = swComp.GetChildren

For i = 0 To UBound(vChildComp)

Set swChildComp = vChildComp(i)



TraverseComponent swChildComp, nLevel + 1


set CompModeldoc2 = swchildcomp.getmodeldoc


Next i

End Sub

Sub main()

Dim swApp As SldWorks.SldWorks

Dim swModel As SldWorks.ModelDoc2

Dim swAssy As SldWorks.AssemblyDoc

Dim swConf As SldWorks.configuration

Dim swRootComp As SldWorks.Component2

Dim bRet As Boolean



Set swApp = CreateObject("SldWorks.Application")

Set swModel = swApp.ActiveDoc

Set swConf = swModel.GetActiveConfiguration

Set swRootComp = swConf.GetRootComponent



Debug.Print "File = " & swModel.GetPathName



TraverseComponent swRootComp, 1

End Sub

'---------------------------------------