---

Hallo API-Freunde,
meine vielen Makros, bei denen ich mit der bekannten Routine:

Code:

---

Option Explicit
Sub TraverseComponent(swComp As SldWorks.Component2)
    Dim vChildComp                  As Variant
    Dim swChildComp                As SldWorks.Component2
    Dim swCompConfig                As SldWorks.Configuration
    Dim i                          As Long
   
    vChildComp = swComp.GetChildren
    For i = 0 To UBound(vChildComp)
        Set swChildComp = vChildComp(i)
       
        TraverseComponent swChildComp
       
    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 t
    t = Timer
    Set swApp = CreateObject("SldWorks.Application")
    Set swModel = swApp.ActiveDoc
    Set swConf = swModel.GetActiveConfiguration
    Set swRootComp = swConf.GetRootComponent3(True)
   
    TraverseComponent swRootComp
   
    Debug.Print Timer - t
End Sub

---

durch die Baugruppe gehe, sind in SWX2011-64bit SP1 unheimlich langsam.
Auf dem 32-Bit-System zeigt die Zeitkontrolle bei ca. 100 Teilen 0,0s an.
Bei der 64-Bit-Maschine sindŽs bei gleicher Baugruppe 1,88s. Da scheintŽs irgendwo zu klemmen.
Kann das jemand bestätigen?
Weiß jemand, wo ich die Bremse lösen kann?
Vielen Dank schon mal jetzt.
Viele Grüße und frohes Schaffen wünscht
Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

na, auch schon bemerkt, daß 64-bit-API bis 100x langsamer?
Willkommen im Club !

Ich habe das Problem schon seit über einem Jahr
und u.a. hier gepostet: http://ww3.cad.de/foren/ubb/Forum2/HTML/019644.shtml

(bisher) einziger workaround: von Makros auf add-in umsteigen!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Das ist ja doof, daß das Problem schon über ein Jahr bekannt ist, und immer noch nichts dagegen gibt.
Welchen Zweck hat dann die tollste Hardware, wenn SWX dann daher kommt und eine Spaßbremse mitbringt?
Schließlich ist ja die 64-Bit-Technologie auch nicht wirklich brandneu.
Na ja: Da muß ich wohl erst mal drüber schlafen und nachdenken, wie ich da mit SWX2011-64bit weitermache. So gehtŽs auf alle Fälle nicht. Alleine die Sache mit der XLS-Stückliste raubt mir den Nerv.
Ich hab ja zu Glück das SWX2011-64bit noch nicht produktiv im Einsatz.
Viele Grüße
Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Thomas,

das "Problem" ist Architekturbedingt, die Lösung wird nicht von SolidWorks kommen können, da die VBA Makros eben nicht mehr im Prozessraum des 64 Bit SolidWorks laufen können. Die Lösung hat dir SLDW-FEM aber auch schon gesagt, umschreiben der Funktionen als Addin, welches dann wieder innerhalb von SolidWorks läuft. So weit zumindest mein Verständnis.

Du kannst mal versuchen ob du mit dem SldWorks.CommandInProgress etwas mehr rausholen kannst, bei ein paar meiner Excelmakros und hat das 80% Laufzeitverkürzung gebracht, allerdings schon bei 32 Bit SolidWorks auf XP, trotzdem könnte ein Versuch auch für 64 Bit nicht schaden.

Ciao,
Stefan

------------------
Inoffizielle deutsche SolidWorks Hilfeseite    http://solidworks.cad.de
Stefans SolidWorks Blog

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Stefan,
vielen Dank für Deine wenig tröstende Antwort.
Ist blöd, daß man den "Fortschritt" hier nicht aufhalten kann.
Schade, wennŽs so bleibt, wie es jetzt ist.
Umprogrammieren scheidet wohl aus, weil zusätzliche Investitionen in Programmierumgebung und Programmieraufwand in dieser Größenordnung z.Z. nicht akzeptiert werden.
Bleibt zu hoffen, daß den Entwicklern bei SWX da doch noch was einfällt.
Viele Grüße
Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,
und Euch allen ein gesundes Neues Jahr...
Nun mein Anliegen:
In SWX2013 soll das Problem, daß die Makro-Fenster nicht von selbst im Vordergrund erscheinen, behoben sein.
Weiß jemand, ob sich der oben beschriebene Geschwindigkeitsverlust nun auch in Rauch aufgelöst hat?
Das wäre für mich ein triftiger Grund, auf SWX2013-64 zu updaten.
Viele Grüße
Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ab SWX2013 ist VBA7.1 implementiert, welches nun wieder im Prozessraum von SWX arbeitet, weil es 32- und 64-bit-fähig ist.
Somit sind die Makros wieder schnell.

Evtl. müssen einige Anpassungen in den Makros gemacht werden.
Vor allem dann, wenn die Windows-API über die declare-Anweisung verwendet wurde.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Vielen, vielen Dank,
dann lohnt sich ja der Umstieg auf SWX2013 allein schon aus der Sicht der Weiterbenutzung meiner Makros....
Viele Grüße
Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Thomas,

ich würde dein Makro zum Abfragen von Bauteilen gerne für meine Zwecke benutzen, aber leider verstehe ich dein Makro so garnicht... 

Vielleicht könntest du es etwas kommentieren.
Das main-Sub ist klar, aber warum er so komisch im anderen Sub springt, ist mir ein echtes Rätsel... Und was er in dem besagten Makro macht dann auch.

Vielen Dank für deine/eure Hilfe!

Gruß,
Kristina

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Da Thomas schon länger nicht mehr da war, versuche ich es mal.
Das 'Herumspringen' nennt sich Rekursion.
Wer Rekursion verstehen will, muss zunächst die Rekursion verstanden haben.

Zu TraverseComponent gibt es in der API-Hilfe mehrere Beispiele.

Gruß, Torsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Torsten

Die Beispiele habe ich bereits gelesen und nicht verstanden. Ich habe sie in ein Makro eingefügt und mit dem Debug-Modus ausprobiert.

Ich habe mir das Beispiel "Traverse Assembly at Component Level Example (VBA)" vorgenommen.

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
    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
        Debug.Print sPadStr & swChildComp.Name2 & " <" & swChildComp.ReferencedConfiguration & ">"
    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
    Dim fileName As String
    Dim errors As Long
    Dim warnings As Long
    Set swApp = CreateObject("SldWorks.Application")
   
    ' Open assembly
    fileName = "X:\Technikerarbeit\3D_Teile\Standardbehälter.sldasm"
    Set swModel = swApp.OpenDoc6(fileName, swDocumentTypes_e.swDocASSEMBLY, swOpenDocOptions_e.swOpenDocOptions_Silent, "", errors, warnings)
    Set swConf = swModel.GetActiveConfiguration
    Set swRootComp = swConf.GetRootComponent3(True)
    Debug.Print "File = " & swModel.GetPathName
    ' Traverse components
    TraverseComponent swRootComp, 1
End Sub

Den Begriff Rekursion verstehe ich. Es ist eher das Problem, dass ich nicht so recht weiß, wie sie im Programmablauf wirkt. Das Sub wird beendet und dann springt er von End Sub auf Debug.Print...
Warum? Es hat sich in dem Moment doch nicht selbst aufgerufen.

Vielen Dank für deine Hilfe,

Kristina

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Thunja:
Es ist eher das Problem, dass ich nicht so recht weiß, wie sie im Programmablauf wirkt. Das Sub wird beendet und dann springt er von End Sub auf Debug.Print...
Warum? Es hat sich in dem Moment doch nicht selbst aufgerufen.

---

Nein, die aufgerufene Sub hat sich dann gerade beendet und das Programm macht in der Zeile weiter, die hinter dem entsprechenden Aufruf steht, also bei Debug.Print der aufrufenden Sub.
Alles gut, genau so soll es sein.
Die Sub ruft sich einfach immer wieder selbst auf, wenn Kind-Komponenten vorhanden sind und macht nach der Abarbeitung in der nächsten Zeile weiter.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Achso, also ähnlich wie verschachtelte Schleifen.

Ist die innerste Schleife(in diesem Fall das zuletzt aufgerufene Sub) zu Ende, so beendet er das nächst Äussere.

Ok, Danke für die klare Antwort.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Thunja:

Ist die innerste Schleife(in diesem Fall das zuletzt aufgerufene Sub) zu Ende, so beendet er das nächst Äussere.

---

Viel besser kann man es eigentlich nicht ausdrücken!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP