---

Hallo zusammen,

hat jemand von euch Erfahrungen mit selbstgestrickten Zusatz-Tools  bei einem Releasewechsel von SWX? Wir (bzw. unser bisheriger CAD-Admin) haben mit MEDUSA auf UNIX die Erfahrung gemacht, daß durch Überbügeln von neuen Versionen viel Arbeit die man in eigen kreierte Zusatzapplikationen gesteckt hat einfach zunichte gemacht wird. Deshalb wird bei uns in dieser Richtung gar nichts unternommen.
Ich persönlich bin der Meinung daß man sich viel Arbeit im Konstruktionsalltag durch kleine Makros, Programme usw. erleichtern könnte, hab aber noch keine Ahnung von der Materie und müßte mich intensiver damit beschäftigen. Wenn da nicht die Angst vor in den Sand gesetzter Zeit wäre....

Für (hoffentlich positive) Rückmeldungen wäre ich dankbar.

Gruß,

Joachim

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

---

Hi Joachim,
ich bin zwar kein "Held" im Programmieren  ,aber meine in SWX 2000 erstellten Makros und Programme laufen auch in SWX 2001. Allerdings ist die Abwärtskompatibilität von 2001 er Makros zu SWX 2000 nicht mehr gegeben (wegen Einführung von VBA?!?). Also mein Tipp:
nicht scheuen, sich kleine "Helfer" zu basteln. Es lohnt sich in jedem Fall!

Viele Grüsse aus dem Schwarzwald
gismo

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

---

wir haben bei uns ca. seit 3 Jahren mehr oder weniger umfangreiche Makros im Einsatz.
Mit Release-Wechseln gabs bei uns noch nie Schwierigkeiten.
Das SWX-Release ist ja auch nicht das Entscheidende - wichtig sind die unterstützten API-Befehle. Es kommt zwar vor, daß der ein oder andere API-Befehl mal durch einen anderen abgelöst wird - das sind aber in der Regel Erweiterungen der vorhergehenden Funktionen.
Bspw. wurde
ModelDoc::AddDiameterDimension
ersetzt durch
ModelDoc::AddDiameterDimension2
in der API-Hilfe findet man dann den Hinweis:
"This method is now Obsolete and has been superceded by ..."
Mir ist aber noch kein Makro wegen einer veralteten Methode hängengeblieben (vielleicht wird die alte Methode trotzdem noch verarbeitet - weiß ich nicht/hab ich nicht probiert). Im schlimmsten Fall muß man eben wie o.g. Bsp. die neue Methode ersetzen (ist doch kein Aufwand einmalig die Erweiterung "2" zu ergänzen).
Kritischer wird es, wenn wie jetzt vor kurzem die gesamte Makrosprache umgestellt wird.
Als vor Jahren M$ seine Makrosprache in Word auf VBA umgestellt hat, gabs zwar einen automatische Konvertierung - raus kam aber nur Schrott, da hat es reihenweise Makros zerschossen, die händig nachbearbeitet werden mußten.
Bei SWX hat der Umstieg auf VBA mit SW2001 bei uns gut geklappt, die Makros sind alle ganz geblieben (war ja aber auch vorher schon Low-Level-VB).
Im übrigen sind bei uns nur einfache, kurze Makros in VBA als *.swp. Umfangreichere Tools sind als externe *.exe-Programme compiliert und hinterlegt (sicherlich auch bedingt aus der Vor-VBA-Zeit - aber ein Wechsel der Makrosprache ist dann eben kein Thema mehr).

------------------
mfg uc

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

---

Hallo,

soweit mir bekannt, wird genau durch die von u.clemens beschriebenen API-Erweiterungen sichergestellt, daß die MakroŽs auch nach Versionswechsel noch funktionieren.

Zitat:

---

Original erstellt von u.clemens:
Es kommt zwar vor, daß der ein oder andere API-Befehl mal durch einen anderen abgelöst wird - das sind aber in der Regel Erweiterungen der vorhergehenden Funktionen.
Bspw. wurde
ModelDoc::AddDiameterDimension
ersetzt durch
ModelDoc::AddDiameterDimension2
in der API-Hilfe findet man dann den Hinweis:
"This method is now Obsolete and has been superceded by ..."

---

Tschüß
Jana

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

---

Hi,
wir haben auch diverse Makros und Programmtools gemacht bzw. selbst im Einsatzt und das schon mit der 98er version bisher ohne Probleme.
Nur schon wie oben erwähnt nicht abwärtskompatibel. Aber wer will schon downgraden 

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

---

Moin moin,

den Ausführungen meiner Vorgänger ist kaum etwas hinzuzufügen.
Nur soviel vielleicht noch:
Eine der Grundbedingungen für eine COM-Schnittstelle ist, dass einmal veröffentlichte Objekte und Methoden auch dann gültig bleiben, wenn andere Methoden ein besseres Verhalten versprechen.
Insofern gibt es zwar "obsolete" Methoden, diese werden aber weiterhin unterstützt, was allerdings oft nur bedeutet, dass SolidWorks nicht beim Aufruf abstürzt!
Man kann also davon ausgehen, dass heute erstellte Makros (danach fragt Joachim) auch für "lange" Zukunft gültig und funktionsfähig bleiben.
Aber: Was bedeutet in der IT schon "lange"? 1 Jahr? 2 Jahre?
Regelmäßige Pflege, auch von selbst erstellter Software, ist sicher ein "Must", nicht nur in Bezug auf SolidWorks Makros.

In dem Sinne, Gruß, Armin

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

---

Ich hatte Probleme!!!

keine grossen, aber immerhin. Es passieren eben doch Aenderungen in den API-Befehlen. Manchmal nur kleine Syntx-Nicklichkeiten. Gerade wenn man ein Makro ueber 2 oder 3 Updates nicht angepackt hat kommen Ueberraschungen. Bei uns war das nie ein Problem, weil ich immer ziemlich genau wusste was die Makros machen. Ich weiss aber nicht wie das ist, wenn jemand anderes meinen Code Pflegen soll. Das sollte man immer beachten. Ich habe deswegen selten Makros geschrieben und fuer viele Anwender bereitgestellt.

Bird

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