【转帖】api code speed and sw menu activation
 

api code speed and sw menu activation?
while running some code from excel that is accessing an active solidworks assembly thru the api, the code execution speeds up dramatically only when a top drop-down menu in solidworks is activated, or a built-in dialog box such as 'open file' is displayed.
why is this happening, and is there sw api code to silently reproduce this effect in the background? i have tried switching off graphics updates (enablegraphicsupdate = false) so far with no change.
we will need to see the actual code you are referring to
here is an example that can be pasted into a module in an excel vba project
if you run it on small assembly (maybe 20 components), you can experiment with:
starting the excel macro, then just activating sw
starting the excel macro, then activating sw and selecting a top menu and letting it stay activated while the macro runs
i get quite a difference in message box times when i try this (about 500% faster when using a menu in sw, i have been selecting "window")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dim swapp as sldworks.sldworks
dim swmodel as sldworks.modeldoc2
dim prog as integer
option explicit
sub example1()
dim swassy as object
dim swrootcomp as object
dim bret as boolean
dim rw as long
dim timerstart as long
set swapp = createobject("sldworks.application")
set swmodel = swapp.activedoc
set swconf = swmodel.getactiveconfiguration
set swrootcomp = swconf.getrootcomponent
set swassy = swmodel
application.screenupdating = false
timerstart = timer
traversecomponent swrootcomp
msgbox timer - timerstart
end sub
sub traversecomponent(swcomp as object)
dim vchildcomp as variant
dim swchildcomp as object
dim swchmodel as object
dim i as long
vchildcomp = swcomp.getchildren
for i = 0 to ubound(vchildcomp)
set swchildcomp = vchildcomp(i)
if swchildcomp.issuppressed = false then
set swchmodel = swchildcomp.getmodeldoc
calcshtqty swchmodel
mirrchk swchmodel
prog = prog + 1
traversecomponent swchildcomp
end if
next i
end sub
sub calcshtqty(swmodel as sldworks.modeldoc2)
dim swmodelext as sldworks.modeldocextension
dim nstatus as long
dim swcfg as sldworks.configuration
dim vmassprop as variant
dim modelvol as long
set swcfg = swmodel.getactiveconfiguration
vmassprop = swmodel.getmassproperties2(nstatus)
modelvol = 61023 * (vmassprop(3))
end sub
function mirrchk(swmodel as sldworks.modeldoc2) as boolean
dim featcount as integer
dim i as integer
dim main_feat_typ_name as string
on error resume next
dim mainfeature as sldworks.feature
featcount = swmodel.getfeaturecount
for i = featcount to 1 step -1
set mainfeature = swmodel.featurebypositionreverse(featcount - i)
main_feat_typ_name = mainfeature.gettypename
if main_feat_typ_name = "mirrorstock" then
mirrchk = true
exit for
end if
next i
end function
oh, swmodel.setblockingstate swfullblock (& others) didn't affect this either, fwiw
looking over your code i cannot see any reason why having a menu active would speed things up; saying that however, having a menu active may bypass certain sw internal checks due to disabling certain procedures from being possible while a menu is open, but nothing that should show a 500% increase of anything near.
i will test this out on a few systems monday and let you know my findings.
in the mean time you may want to start by emptying the traversing function of all code so it runs nothing, then adding each peice of code back line by line until you get the % increase, this wil pin-point the problem area.
thanks for your help, i agree this is strange behavior. i was thinking the same thing about sw disabling procedures, hence my attempt at setting the blocking state. that's all i could immediately find documented in the api that might control this.
the reason the traversing and material quantity calculation procedures are in the code are to slow it down, or that is, to add more resolution to the time test. if the code runs faster, the difference will still be there, it will just be less apparent unless you run it on a huge assembly & compare the difference.
i have been able to get similar results no matter what i am trying to achieve via excel connecting to sw, be it custom property work, feature manipulation, etc.
i could just code the same menu selection i am doing with the mouse to achieve the performance gain, but that'd be a definite last resort.
we also came a cross this behavior.
it seems that while a menu is activated, solidworks stops the dynamic highlight feature from working and causes api to work faster.
the same speed up of api can be achieved if you change the focus from the solidworks window to another window.
you might try to disable the dynamic highlight before running the code.
eyal.
edited: 06/02/2008 at 12:14 pm by eyals siryone
quick