---

Moin, moin,

in SolidWorks 2006 SP 5.1 Makro erstellt für den Bereich Zeichnungen.
An diversen lokalen Rechnern, werden die Verweise in VBA verändert.
Wenn diese Verweise dann RICHTIG eingestellt werden, kommt es doch ab und an vor (noch keine Analyse, bei welcher Vorgehensweise), das die alten Pfade erneut herangezogen werden.
Im konkreten Fall, verweisen gewisse Bibliotheken noch auf ältere SolidWorks - Versionen, die aber nicht mehr verfügbar sind, da diese bereits deinstalliert wurden.

Installationsvorgehensweise bei uns:
SolidWorks 2005 --> d:\Programme\SolidWorks2005\....
SolidWorks 2006 --> d:\Programme\SolidWorks2006\....

damit auch mit mehreren Versionen parallel gearbeitet werden kann.

Die VBA - Verweise suchen, nach dem Laden der Zeichnung auf die Pfade:
NOT FOUND : SolidWorks 2005 Constant type library --> Pfad: D:\Programme\SolidWorks2005\sldworks.tlb

Jedoch an anderen Rechnern werden diese Verweise NICHT fälschlicherweise geladen.

Weiß jemand, WER oder WAS die Verweis - Struktur in VBA verändert?
Sind das Einträge in der Registry? Wenn ja, warum bleiben diese nicht konstant erhalten?

Danke im voraus

------------------
Gruß aus Braunschweig
Carsten 

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

---

Guten Morgen,

die SolidWorks Type Library ist in der Registry registriert.
Ich habe dir mal das relevante Kapitel aus der Grundlagenschulung kopiert:

1.4 Die SolidWorks ProgId und Registryschlüssel

Damit Sie in einem externen Visual Basic Projekt auf SolidWorks zugreifen können, benötigen Sie eine Objektinstanz zur SolidWorks Application.

Es gibt in VB.Net zwei Möglichkeiten eine solche Instanz zu erstellen. Die benötigten Funktionen sind in den Net Klassen Microsoft.VisualBasic enthalten und heißen CreateObject und GetObject.

Bevor wir uns mit diesen Funktionen näher beschäftigen, schauen wir uns die SolidWorks Registryeinträge in der Windows Registry genauer an.

Da die SolidWorks Type Library bei der Installation von SolidWorks auf Ihrem System registriert wurde, sind in der Registry die benötigten Einträge vorhanden.
Unter anderen erfahren wir hier die ProgId (also den Namespace und Klassennamen) der SolidWorks Type Library, welche wir bei beiden Funktionsaufrufen benötigen.

Öffnen Sie den Registrierungs-Editor, indem Sie zum Beispiel „RegEdit“ in das Windows Ausführenfenster eingeben.
Suchen Sie im Registrierungs-Editor nach „SldWorks“. Für die Suche klicken Sie bitte auf den Registryschlüssel „HKEY_CLASSES_ROOT. Starten Sie die Suche durch Strg+F oder im Menü Bearbeiten. Geben Sie im Suchen Dialog „SldWorks.Application“ ein und klicken Sie auf „Weitersuchen“.

Klicken Sie auf „Weitersuchen“ oder F3 bis Sie den Registryschlüssel „SldWorks.Application“ angezeigt bekommen.
(Alternativ können Sie auch in der Baumstruktur des „HKEY_CLASSES_ROOT“ Schlüssel nach „SldWorks.Application“ suchen, indem Sie mit dem Scrollbalken zu diesem Schlüssel scrollen.)

Nach langer Suche sollten Sie den Registryschlüssel gefunden haben und ähnliches im Registrierungs-Editor angezeigt bekommen.

Sie sehen, dass es mehrere „SldWorks.Application“ Schlüssel gibt. Die Erklärung ist einfach.
Der Registryschlüssel „SldWorks.Application“ steht für die zuletzt auf Ihrem System gestartete SolidWorks Version.
Die Schlüssel „SldWorks.Application.x“ stehen für eine bestimmte SolidWorks Version.

Registryschlüssel SolidWorks Version
SldWorks.Application.11 SolidWorks 2003
SldWorks.Application.12 SolidWorks 2004
SldWorks.Application.13 SolidWorks 2005
SldWorks.Application.14 SolidWorks 2006
SldWorks.Application.15 SolidWorks 2007

Keine Angst, wenn in Ihrer Registry SolidWorks Versionsschlüssel fehlen. Diese sind von den installierten SolidWorks Versionen abhängig.

Der wichtige Eintrag in diesen Registryschlüssel ist der Unterschlüssel „CLSID“.
Dieser enthält die Information auf welche Type Library Ihr System zugreift, da eine CLSID (Klassen ID) eine Klassenbibliothek eindeutig auf Ihrem System definiert.

Betrachten wir zur Verdeutlichung den Schlüssel „SldWorks.Application“ und dessen „CLSID“ Unterschlüssel. Mit Hilfe dieses Eintrags können Sie ermitteln, welche SolidWorks Version zuletzt gestartet wurde, indem Sie die CLSID mit denen der Versionsschlüssel vergleichen.

Ich hoffe diese Informationen helfen dir.

------------------
Mfg Daniel

Wer A sagt, der muss nicht B sagen. Er kann auch erkennen, dass A falsch war. Bertolt Brecht
------------------
SolidWorks | API | Makro | Schulung | Freeware | Schuler Design Automation GmbH

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

---

Den Streß mit den Verweisen bei jedem Versionswechsel kann man vermeiden, wenn man alle Makros konsequent mit late binding (as object) programmiert - dann sind sie versionsunabhängig...

------------------
Lutz Federbusch
Mein Gästebuch
Der Mensch, Herr oder Sklave der Technik?

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

---

Also dieser Empfehlung kann ich auf keinen Fall was abgewinnen.

Es hat mehr Nachteile nach als Vorteile wenn man alle SolidWorks Objekte als Object deklariert.
Man vermeidet Fehler, bekommt Unterstützung in der VBA-Umgebung und erhöht die Lesbarkeit des Codes.
Man sollte immer die frühe Bindung versuchen und im Fall von SolidWorks ist das ja ohne größeren Aufwand möglich!

------------------
Mfg Daniel

Wer A sagt, der muss nicht B sagen. Er kann auch erkennen, dass A falsch war. Bertolt Brecht
------------------
SolidWorks | API | Makro | Schulung | Freeware | Schuler Design Automation GmbH

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

---

Da sind wir wohl nicht einer Meinung; auf die Unterstützung in der Entwicklungsumgebung (über die bessere Lesbarkeit könnte man sich auch streiten) kann ich gerne verzichten, wenn ich die Makros dafür ohne Nacharbeit in mehreren SW-Versionen auf jedem Rechner nutzen kann, was ich täglich tue.

------------------
Lutz Federbusch
Mein Gästebuch
Der Mensch, Herr oder Sklave der Technik?

[Diese Nachricht wurde von Lutz Federbusch am 01. Aug. 2007 editiert.]

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

---

Zitat:

---

Original erstellt von Lutz Federbusch:
Da sind wir wohl nicht einer Meinung

---

Soll vorkommen  , und auch gut, denn so kann sich jeder das aussuchen, was man persönlich favorisiert.

Ich persönlich binde immer die aktuellste Type Library in meine Projekte ein und unterscheide dann im Code per SldWorks.RevisionNumber die Version. Somit verwende den richtigen und aktuellsten Code für die richtige Version.

------------------
Mfg Daniel

Wer A sagt, der muss nicht B sagen. Er kann auch erkennen, dass A falsch war. Bertolt Brecht
------------------
SolidWorks | API | Makro | Schulung | Freeware | Schuler Design Automation GmbH

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

---

Danke für eure herrliche Diskussion, kann irgendwie von beiden etwas gewinnen.
Aber bitte schreibt doch mal, (Lutz), wie ich das

late binding (as object)

einsetzen soll. Und an: Daniel:
WIE binde ich die

aktuellste Type Library in meine Projekte und unterscheide dann im Code per SldWorks.RevisionNumber die Version ?

Dann wäre mir sehr sehr geholfen :-)

Danke im voraus, allen Beteiligten

------------------
Gruß aus Braunschweig
Carsten 

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

---

SolidWorksVerweiseInVBA.jpg

Hallo Carsten,

in der SolidWorks VBA Umgebung gelangst du unter Extras > Verweise zum Verweise Dialog.
In diesem Dialog wähle ich immer meine aktuellste SolidWorks Type Library aus (siehe Bild SolidWorksVerweiseInVBA.jpg), in meinem Fall z.B. SolidWorks 2008.
Zuvor musst du die bestehenden SolidWorks Verweise abwählen, da man nicht gleichzeitig auf mehrere Versionen verweisen kann.

Im Code frage ich, wie gesagt per SolidWorks.RevisionNumber, die Version ab.
Dieser Befehl liefert dir die Version in einem String mit dem Aufbau Hauptversion.Servicepack.Revision.
Die Hauptversion ist meist die entscheidende, also kannst du den String am ersten Punkt splitten und dir die Hauptversion in einer Variablen merken.
Die SolidWorks Version in Jahr sind:

• 11 = SolidWorks 2003
  
• 12 = SolidWorks 2004
  
• 13 = SolidWorks 2005
  
• 14 = SolidWorks 2006
  
• 15 = SolidWorks 2007
  
• 16 = SolidWorks 2008
  

oder einfach Hauptversion + 1992 = Jahr

Mit Hilfe einer Select Case Anweisung kannst du dann im Code die verschiedenen (auf eine bestimmte SolidWorks Version bezogenen) Codebestandteile aufrufen.
Dies ist aber nicht immer nötig. Es ist nur dann wichtig wenn der Code z.B. auch in SolidWorks 2003 funktionieren soll, du aber in der SolidWorks 2006 API eine schönere und schnelle Variante gefunden hast. Dann verwendetes du bis zur Version 14 den alten Code und ab Version 14 den neuen.

So einfach ist das!

------------------
Mfg Daniel

Wer A sagt, der muss nicht B sagen. Er kann auch erkennen, dass A falsch war. Bertolt Brecht
------------------
SolidWorks | API | Makro | Schulung | Freeware | Schuler Design Automation GmbH

[Diese Nachricht wurde von tbd am 01. Aug. 2007 editiert.]

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

---

Wenn Du mitten im Code die Version abfragst und je nach Version unterschiedliche Routinen ausführen willst, mußt Du aber bei den Verweisen für jede Version die Typbibliothek einbinden.
Auf Rechnern, auf denen dann auch nur eine der Versionen nicht installiert ist, läuft der Code dann nicht. Die Methode taugt also nur für Einzelkämpfer oder streng vorhersagbare Umgebungen.

Wer viele Programme/Makros im Einsatz hat und die noch dazu auf jedem Rechner unter beliebigen Versionen auch im nächsten Jahr noch ausführen will, sollte eher zum late Binding greifen. Was das ist kann man in der API-Hilfe nachsehen (im Index "late"). Betrifft nur die Deklaration von Objekten.

------------------
Lutz Federbusch
Mein Gästebuch
Der Mensch, Herr oder Sklave der Technik?

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

---

Hallo zusammen,

ich bin auch ein Gegner von Early Binding in produktivem Code, das gibt nur Scherereien, Nachfragen, Laufzeitprobleme, frustierte Anwender und genervte Admins; ich hab nicht umsonst alle meine Quellcodebeispiele hier im Brett, die Makros, Tools und Programme in der MakroMania und selbst meine Shareware wie das Batchprint, Batchexport und Batchmakro Tool PAC4SWX konsequent mit late binding programmiert.

Ich sehe ehrlich gesagt für die Anwender auch keinen der Vorteile, wie Daniel die beschreibt:

* Man vermeidet Fehler
Ich erzeuge beim Anwender mehr Probleme und Fehler durch die blöden Verweise bzw. hab Programme, die auf neuen/alten Version nicht mal starten wollen. Ich wüßte auch nicht, wie ich mehr Fehler dadurch vermeide, wie wenn ich sorgfältig programmiere und auf die Typen achte.

* bekommt Unterstützung in der VBA-Umgebung
Who cares? Der Anwender bestimmt nicht. Wenn es mir mal zu blöde wird in der Hilfe die Syntax nachzuschlagen setze ich während der Entwicklung die Verweise und nutze das Early binding, vor der Veröffentlichung nehme ich die Verweise wieder weg und deklariere halt alle Objekte wieder um auf 'as Object'. Das macht es meinen Anwendern einfacher 

* und erhöht die Lesbarkeit des Codes
Hm, das ist in meinen Augen auch kein Argument. Wenn ich eine Variable oben mit

  Dim HuddelUndBrassel as SldWorks.ModelDoc2

deklariere und unten dann irgendwo

  Set HuddelUndBrassel = ...

nutze ist das nicht besonders lesbar. Ich verwende dann lieber

  Dim oComponentModelDoc as Object

und weiß aufgrund des Variablennamens, was gemeint ist 

Unterm Strich für mich aus der Sicht des Anwenders keine Vorteile, aber viele Nachteile durch die Verwendung von Early Binding --> ich lass es für nicht rein privaten Code sein 

Ciao,
Stefan

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

Member of CAD.de BOINC Team  -   | Seti@Home | CPDN | Einstein@Home

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

---

Hallo Stefan,

na gut, bei einem Makro sehe ich es ja ein. Es ist ja nicht so, dass ich mich nicht überzeugen lasse.
Wenn man allerdings eine externe Anwendung entwickelt, bleibe ich bei meiner Meinung.
Zum Beispiel im kostenlosen Visual Studio 2005. Dort sollte man die Optionen "Option Explicit" und "Option Strict" auf on setzten.
Dies garantiert eine sichere und korrekte Typenumwandlung.
Auch bekomme ich durch die SolidWorks Verweise und richtig deklarierten Objekte die Unterstützung durch IntelliSense. So liefert einem die Entwicklungsumgebung zum Beispiel genau welche Parameter die Methode benötigt und was sie als Rückgabewert liefert.
Das Net.Framework im Visual Studio benötigt für einen SolidWorks Verweis eine umgewandelte Typbibliothek. Mit TlbImp kann man dann eine bestimmte SolidWorks Version in eine Common Language Runtime-Assembly umwandeln und ist, von der Version her gesehen, immer auf der sicheren Seite.
Diese SolidWorks Assembly liefert man im Projekt mit und es gibt keine Probleme!
Auch SDA-4Free (ich kann das auch  ) wurde so von mir entwickelt. Damit konnte ich das Problem der ständig wechselnden Add-In Methoden aus dem Weg gehen. In jeder SolidWorks Version wird der aktuelle Sprachsatz verwendet. Somit stehen den User auch immer alle Möglichkeiten in SolidWorks zur Verfügung, welche in der aktuellen Version bereit gestellt werden.

Das ist meine Meinung. Ich glaube über dieses Thema kann man stundenlang ohne wirklichem Ergebnis diskutieren.

------------------
Mfg Daniel

Wer A sagt, der muss nicht B sagen. Er kann auch erkennen, dass A falsch war. Bertolt Brecht
------------------
SolidWorks | API | Makro | Schulung | Freeware | Schuler Design Automation GmbH

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

---

Danke euch allen, für die spontane Unterstützung.
Bin nun um einige Informationen reicher und werde diese umsetzen.

------------------
Gruß aus Braunschweig
Carsten 

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

---

Hi zusammen,

Ich Persönlich nehme immer (wenn möglich) LoadLibrary/LoadLibraryEx damit ich meine dll's/exe'n nicht im System32 oder in einem Umgebungsvariablen Pfad verteilen muss...

damit kann man dll's laden welche sich in einem bestimmten Verzeichnis befinden z.b. App.Path\Bin, und hat auch kein Problem mit der entsprechenden Version der dll/exe da diese sich beim Programm befindet.

Das hilft natürlich nicht bei den Verweisen und dem CrateObject("Excel.Application.11") ein einfaches CreateObject("Excel.Application") geht bekanntlich immer auf die unter
dem RegKey eingetragene Version HKEY_CLASSES_ROOT\Excel.Application\CurVer (Aufpassen machne Programme ändern gerne mal den Wert damit die zuletzt verwendete Version gestartet wird)

Gruß
Micha

------------------
Stell dir vor, es geht, und keiner kriegts hin.

 

Zitat:

---

Interpunktion und Orthographie des Postings sind frei erfunden.
Eine Übereinstimmung mit aktuellen oder ehemaligen Regeln wäre rein zufällig und ist nicht beabsichtigt.

---

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

---

Ist zwar schon ein Weilchen her, aber trotzdem "Danke" an alle Beteiligten, auch wieder was dazu begriffen 

------------------
Klaus

www.al-ko.com | mein Gästebuch | privat... | Nasenheim 

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