1957 Tipps, Tricks und Artikel für Inventoranwender |
13.03.2017 - 17.03.2017
5-tägig
Autodesk Inventor Grundlagen
D-88046 Friedrichshafen
Details und Anmeldung
28.03.2017 - 31.03.2017
4-tägig
AutoCAD/AutoCAD LT Grundlagen
D-88046 Friedrichshafen
Details und Anmeldung
05.04.2017 - 06.04.2017
2-tägig
Autodesk Inventor Professional - FEM & Dynamische Simulation (kompakt)
D-88046 Friedrichshafen
Details und Anmeldung
08.05.2017 - 12.05.2017
5-tägig
Autodesk Inventor Grundlagen
D-88046 Friedrichshafen
Details und Anmeldung
22.05.2017 - 23.05.2017
2-tägig
Autodesk Inventor Professional - FEM & Dynamische Simulation (kompakt)
D-88046 Friedrichshafen
Details und Anmeldung
29.05.2017 - 01.06.2017
4-tägig
AutoCAD/AutoCAD LT Grundlagen
D-88046 Friedrichshafen
Details und Anmeldung
Alle MUM Schukungsangebote findet ih hier.
Teil 7 verpasst? Dann erstmal hier weiter!
Im letzten Teil haben wir uns mit der Fehlerbehandlung innerhalb unserer Programme gekümmert, einem sehr wichtigen Thema! Um die Beispiele weiterhin einfach zu halten, werde ich aber in den weiteren Programmen darauf verzichten. Ihr wisst jetzt ja, was bei einem normalen Programm für die freie Wildbaren zu tun ist.
Heute schauen wir uns an, wie wir Mehrfachänderungen mittels eines Rückgängigbefehls rückgängig machen können. Wie brauchen dazu als Ausgangspunkt unser Programm aus dem Teil 6, das wir zum (un-)sichbar schalten von Skizzen in Bauteilen innerhalb einer Baugruppe genutzt haben. Wer das Programm nicht mehr hat, schaue in Teil 6 nach. Zuerst wieder den VBA-Editor starten und unser Benutzerprojekt laden. Dort sollten wir das Programm SkizzeUnsichtbar finden. Damit das ganze funktioniert, brauchen wir wieder eine Baugruppe.
Wenn wir das Programm ausführen und alle Skizzen sichtbar schalten funktioniert das zwar hoffentlich gut. Wer nach dem Programmende aber auf den Rückgängigknopf im Inventor betätigt, wird feststellen, das jeder Skizzen einzeln wieder unsichtbar wird. Wurden z.B. 20 Skizzen sichtbar gemacht, so muss 20x Rückgängig gemacht werden. Das lässt sich verhindern, indem wir die gesamte Transaktion "Skizzen unsichtbar machen" zu einem "Paket" zusammenfassen. Dazu brauchen das Objekt Transaction, das wir definieren und dem wir dann wie gehabt was zuweisen.
Dim oTrans As Transaction
Set oTrans = ThisApplication.TransactionManager.StartTransaction(oAsmDoc, "Skizzensichtbar")
oAsmDoc entspricht hier dem Objekt, das die Baugruppe enthält (Haben wir oben der aktuelle Baugruppe zugewiesen!). "Skizzensichtbar" ist der Name der Transaktion.
Dann kommt der Programmablauf, den wir zu einer Transaktion zusammenfassen wollen, also in unserem Fall die Schleifenkonstruktion For Each....
Wenn die Schleife durch ist, dann beenden wir die Transaktion durch ein oTrans.End.
Stellt sich noch die Frage, wo die Zeilen innerhalb unseres Programmes stehen sollten? Hier habe ich Sie platziert:
Dann können wir nun ausprobieren, ob das ganze funktioniert. Schließe die IAM ohne zu speichern und öffne sie wieder. Starte das Programm, mach alle Skizze sichtbar und klicke dann auf Rückgängig. Jetzt sollte alles, was das Programm gemacht hat, mit einem Klick rückgängig gemacht sein. Hier der vollständige Programmcode.
Public Sub SkizzeUnsichtbar1() Dim oAsmDoc As AssemblyDocument Set oAsmDoc = ThisApplication.ActiveEditDocument Dim oRefDocs As DocumentsEnumerator Set oRefDocs = oAsmDoc.AllReferencedDocuments Dim oRefDoc As Document Dim Antwort Dim wfBoolean As Boolean wfBoolean = False Antwort = MsgBox("Alle Skizzen Sichtbar (Ja) oder Unsichtbar (Nein)", vbYesNo) If Antwort = vbYes Then wfBoolean = True If Antwort = vbCancel Then Exit Sub Dim osketch As PlanarSketch Dim oTrans As Transaction Set oTrans = ThisApplication.TransactionManager.StartTransaction(oAsmDoc, "Skizzensichtbar") For Each oRefDoc In oRefDocs If oRefDoc.IsModifiable = True And oRefDoc.DocumentType = kPartDocumentObject Then For Each osketch In oRefDoc.ComponentDefinition.Sketches osketch.Visible = wfBoolean Next End If Next oAsmDoc.Update oTrans.End End Sub
Das soll es für heute gewesen sein, Bis zum nächsten mal. Eine viel bessere, umfangreichere Beschreibung zu Thema Transaction findet ihr übrigens hier, falls ihr das Thema vertiefen wollt. Schaut euch vorallem an, was dort zum Thema Errorhandling und Transaction beschrieben wird.
Gerade bei Problemen und wenn es um die Systemüberwachung geht (compass.ini, Vault Logdateien,…) kann es sinnvoll sein, die Änderungen/Ergänzungen in Logdateien zu verfolgen. Dafür kann PowerShell genutzt werden.
[Quelle ct Magazin]
Autodesk hat ein Tool zur Verfügung gestellt, mit dem das System daraufhin untersucht werden kann, ob es die Anforderungen für eine bestimmte Software erfüllt. Es kann von dieser Seite heruntergeladen werden.
Nach dem Herunterladen und installieren gibt es unter den Programmen einen Autodesk Prerequisite Checker der nach dem Start das System analysiert…
…und danach das Ergebnis in einer Liste darstellt. Oben rechts kann die Programmversion und das Programm selbst gewählt werden. Im Filemenü kann eine einfache (textform) Darstellung oder die HTML (Render) Darstellung gewählt werden. Bei manchen Warnungen schießt das Tool etwas über das Ziel hinaus (20 GHz CPU?!?)
Die Meldungen werden in Warnings (gelb), Errors (orange) und Block Issues (rot) unterteilt. Dazu auf der Downloadseite mehr. Auf den ersten Blick bringt das Tool mehr Verwirrung als Nutzen. Es meckert auf meinem Rechner einige Sachen an (wobei vieles Blödsinn ist) obwohl der Inventor läuft wie der Teufel.
Teil 6 verpasst? Dann erstmal hier weiter!
In Teil 6 haben wir ein Programm geschrieben, dass Skizzen in Bauteilen (un-)sichtbar geschaltet hat. Dabei sind wir über eine Schleife durch alle Skizzen innerhalb eines Bauteiles gelaufen. Dieses Schleifenkonstruktionen sind in der Programmierung sehr wichtig, weil wir eben häufig wiederkehrende Prozesse für mehrere Dateien ausführen wollen.
Was wir bisher aber nicht besprochen haben, ist die Fehlerbehandlung. Ein Fehler kann in einem Programm immer mal auftreten und darauf sollten wir reagieren um zu verhindern, dass unserer Programm aus dem Tritt kommt. Dazu schauen wir uns hier ein paar Möglichkeiten an.
Wer Programme nur für sich schreibt, muss beim Errorhandling nur das Abfangen, was er für nötig erachtet. Wenn das Programm aber auch von anderen Kollegen oder gar von Fremden genutzt wird, dann sollte es so sein, dass es unter keinen Umständen zu einem Programmabbruch mit Fehlermeldung kommt, weil das die meisten Leute verwirrt und sie nicht wissen, das sie tun sollen. Und Programme, die ohne Aufsicht laufen, dürfen sowieso nicht einfach hängenbleiben.
Die Fehlerbehandlung ist eine sehr komplexe Sache, weil man zum einem alle Eventualitäten im Ablauf berücksichtigen muss und zudem noch die Anwendungsfehler des Benutzer abfangen muss. Das kann in Arbeit ausarten ;) Im weitesten Sinne gehört dazu auch das Thema, das der Programmablauf nicht durch Meldungen durch den Inventor unterbrochen wird.
Dieses Thema hatten wir schon. Programmabläufe werden unterbrochen, wenn der Inventor z.B. beim Öffnen einer Datei eine Dialogbox bringt, die wir erst wegklicken müssen, bevor es weiter geht. Dazu hatten wir im Beispiel mit dem PDF-Export der Zeichnung folgende Funktion genutzt:
ThisApplication.SilentOperation = True
Bei Programmende oder einem Programmabbruch durch einen Fehler muss der Wert wieder auf False gestellt werden, sonst bekommt der Anwender auch keine Dialoge mehr, was etwas blöd wäre.
ThisApplication.SilentOperation = False
Manche Meldungen lassen sich so aber auch nicht abstellen. Es besteht noch die Möglichkeit, den Inventor von "außen" zu steuern und als unsichtbaren Prozess zu starten, aber dafür können wir kein Inventor-VBA nutzen, weil der Invenor ja sichtbar da sein muss, wenn wir ein VBA-Programm darin ausführen wollen.
Die nächste wichtige Sache ist das Abfragen, ob eine Aktion überhaupt ausführbar ist. Wir haben z.B. im letzten Beispiel erst geprüft, ob die Datei ein Bauteil und änderbar ist:
If oRefDoc.IsModifiable = True And oRefDoc.DocumentType = kPartDocumentObject Then
Oft kann ein Programm nur für einen bestimmte Dateityp genutzt werden und darf erst gar nicht weitermachen, wenn gerade die falsche Art von Datei im Inventor geöffnet ist.
If ThisApplication.ActiveDocument.DocumentType <> kDrawingDocumentObject Then
MsgBox ("Programm funktioniert nur bei Zeichnungen! Bitte Zeichnung öffnen und nochmals probieren")
Exit Sub
End If
Was auch passieren kann: Das Programm wird ausgeführt und es ist keine Datei geöffnet. Dieser Fehler tritt zwar selten auf aber möglich ist er.
If ThisApplication.Documents.Count = 0 Then
MsgBox ("Es ist keine Datei geöffnet. So wird das nichts werden!")
Exit Sub
End If
Es wird Zeit, den VBA-Editor zu starten, unser VBA-Projekt zu laden und eine neue Public Sub zu machen. Darin stellen wir die SilentOperation auf True und machen die beiden Abfragen rein.
Wenn nun keine Datei geöffnet ist oder die aktuelle Datei ist keine Zeichnung kommt eine entsprechende Meldung und dann des Exit Sub wird das Programm komplett beenden.
Diese ganze Abfrage, ob das aktuelle Dokument (oder die aktuelle Komponenten, wenn man eine Baugruppe durchläuft) kann recht kompliziert werden, weil es manchmal nicht genügt, zu prüfen ob es sich um ein Bauteil handelt, sondern es muss vielleicht auch geprüft werden, ob es sich um eine abgeleitete Komponente oder ein Substitutionsdokument (Ableitung einer IAM) handelt. Dazu ist es hilfreich, sich mal die Eigenschaft des zu bearbeitenden Dokuments anzuschauen. Das kann in der Hilfe oder mittels eines Haltepunkts, der nach dem setzen eines Documentobjekts erfolgen.
Wir ändern die zweite Abfrage auf das Bauteilobjekt und setzen ein oDoc auf das aktuelle Dokument. Dann noch eine Haltepunkt auf End Sub und wir können uns das aktuelle Bauteildokument im Locals-Fenster anschauen.
Dort sehen wir z.B. das es eine Eigenschaft IsSubstitutePart gibt, die eben True oder False ist. Viele Dinge funktionieren nicht, wenn hier true steht.
Stellt sich die Frage, wie man da drauf kommen soll? Ganz einfach, testet eure Programme vorher mit einigen typischen Dateien die möglichst alle Arten von Daten enthält, z.B. Baugruppen mit Unterbaugruppen, schreibgeschützten Dateien, Blechen, iParts, abgeleitete Komponenten usw. Ich habe mir dazu eine Testbaugruppe erstellt, die alle möglichen Arten von Daten enthält. Macht euch Inventor Testprojekt, kopiert euch Dateien unterschiedlichster Art zusammen und fügt sie in eine IAM ein. Ihr könnt auch die Inventor Samples nutzen und euch daraus eine Testbaugruppe bauen.
Bisher haben wir alles mögliche unternommen, das ein Fehler erst gar nicht auftreten kann, indem wir z.B. geprüft haben, das der Dateityp stimmt, die Datei änderbar ist usw. Trotzdem kann es vorkommen, das ein Fehler auftritt, weil wir vielleicht nicht alle Eventualitäten bedacht haben oder Anwender sich noch "seltsamer" anstellt, als wir es uns in unseren dunkelsten Albträumen vorstellen können.
Wir wollen bei unserem Testprogramm einen Fehler provozieren, indem wir eine Division durch 0 durchführen, was ja bekanntlich nicht so wirklich geht. So sieht der Programmcodeabschnitt aus.
Wenn wir das Programm starten, bekommen wir eine Fehlermeldung, die sogar recht aussagekräftig ist: Division by zero.
Wer in dem Fenster auf "End" klickt beendet das Programm. Beim Klick auf Debug wird der Programmablauf in der fehlerverursachenden Zeile angehalten (ähnlich einem Haltepunkt) und man kann im Localfenster die Variableninhalte prüfen und sich Gedanken machen, warum ein Fehler aufgetreten ist.
Was wir nun wollen, ist das bei einem Fehler in einer Zeile diese einfach übergangen wird und das Programm mit der nächsten Zeile weitermacht. Wir brechen das Programm ab und ergänzen folgenden Zeile vor dem Block mit der Berechnung:
Starten wir nun das Programm, bricht es nicht mehr in der Zeile x = 10 / 0 ab sondern übergeht den Fehler und ruft die Messagebox auf, die als Wert für x inf ausgibt. Jetzt könnte man ja sagen "Spitze, dann sage ich meinem Programm einfach, das es bei einem Fehler mit der nächsten Zeile weitermachen soll und ich bin alle Probleme los". Leider ist es nicht so einfach. Ist eine Zeile essenziell für die weitere Programmausführung, wird aber übergangen, dann kommt das gesamte Programm aus dem Tritt. On Error Resume Next muss mit bedacht und Plan eingesetzt werden! Da die Anweisung für jeden Fehler in einer belieben folgenden Zeile gilt, muss dem Programm auch irgendwann gesagt werden, dass es jetzt nicht mehr einfach bei einem Fehler weitermachen soll. das erreicht man durch On Error goto 0
Im obigen Beispiel verursacht x = 20 / 0 wieder einen Fehler.
Will man bei einem Fehler nicht einfach mit der nächsten Zeile weiter machen (was meisten keine gute Idee ist, aber ich wiederhole mich) sondern eine Art Fehlerreoutine aufrufen, nutzt man on Error goto ...
Wir entfernen alle On Error Anweisungen (oder kommentieren sie aus) und machen anstelle dessen am Programmanfang ein On Error goto Fehlerbehandlung
Ein Goto springt zu einem Sprungziel, mit dem entsprechenden Name. Und On Error sollte klar sein. In Summe: Bei Fehler springe zum Sprungziel mit Namen Fehlerbehandlung.
Jetzt müssen wir das Sprungziel auch noch definieren. Das machen wir am Ende des Programm. Einfach den Sprungzielnamen gefolgt von einem Doppelpunkt schreiben:
Führen wir jetzt das Programm aus, springt wir direkt zu Fehlerbehebung und danach kommt nur noch End Sub, d.h. das Programm ist zu Ende. Was nicht passiert, ist das SilentOperation = False gesetzt wird (dazu müssten wir Fehlerbehandlung: vor die Zeile setzen) und es kommt auch keine Fehlermeldung. Der Anwender merkt nur, das nichts passiert. Wir ergänzen also unterhalb des Sprungziels zumindest eine Meldung und wir wollen, das im Fehlerbehandlungsblock auf alle Fälle SilentOperation = False gestzt wird.
Führen wir jetzt unser Programm aus, bekommen wir die entsprechende Meldung, SilentOperation wird ausgeschaltet und dann ist das Programm vorbei.
Jetzt machen wir eine kleine Änderung im Programm, so dass kein Fehler mehr auftritt.
Führen wir das Programm nun aus, bekommen wir eine Meldungsbox mit dem Berechnungsergebnis und dann kommt leider aber die Fehlermeldung, weil das Programm einfach über die Sprungmarke spaziert und den Code darunter ausführt. Wir müssen also das Programm vor der Sprungmarke beenden. Wenn wir dort angekommen sind, war ja alles in Ordnung. Dazu setzen wir direkt vor die Sprungmarke ein Exit Sub. Das Sprungziel Fehlerbehandlung wird nur noch erreicht, wenn ein Fehler auftritt, was ja auch genau das ist, was wir wollen.
Jetzt bekommen wir zwar eine Meldung, das ein Fehler aufgetreten ist, aber wir wissen nicht welcher. In unserem Fall war es ja Division by Zero. Wenn ein Fehler auftritt, gibt es ein Objekt Err das z.B. eine Eigenschaft Description hat, das wir uns in der Dialogbox anzeigen lassen wollen. Dazu verknüpfen wir den Meldungstext mittels des & dann kommt ein Zeilenumbruch und dann wieder ein & und der Fehlermeldungstext.
Jetzt stellen wird oben wieder auf / 0 um und starten das Programm. Wir bekommen nun neben der Meldung auf die Fehlerbeschreibung, die uns vielleicht hilft, das Problem besser zu verstehen.
So sieht unser fertiges Programm aus:
Und hier in Textform:
Public Sub Fehler() On Error GoTo Fehlerbehandlung ThisApplication.SilentOperation = True If ThisApplication.Documents.Count = 0 Then MsgBox ("Es ist keine Datei geöffnet. So wird das nichts werden!") Exit Sub End If If ThisApplication.ActiveDocument.DocumentType <> kPartDocumentObject Then MsgBox ("Programm funktioniert nur bei Bauteilen! Bitte Bauteil öffnen und nochmals probieren") Exit Sub End If Dim oDoc As PartDocument Set oDoc = ThisApplication.ActiveDocument 'On Error Resume Next Dim x As Double x = 10 / 0 MsgBox (x) 'On Error GoTo 0 x = 20 / 1 ThisApplication.SilentOperation = False Exit Sub Fehlerbehandlung: MsgBox ("Es ist ein Fehler aufgetreten. Tut mir Leid :(" & vbCr & Err.Description) ThisApplication.SilentOperation = False End Sub
Das war's für heute.Bis zum nächsten mal bei unserem kleine Programmierkurs.
PS: Weitere Infos zum Errorhandling gibt es auch in der Hilfe.
Über die Autodesk Desktop App kann das Update 3.1 für Inventor 2017 heruntergeladen werden. Natürlich muss vorher Das Update 3 installiert worden sein.
Kunde ohne Subscription, die das Service Pack 2 installiert haben, bekommen den Hotfix 2.3 angezeigt.
Hier die Readme zu den Neuerungen. Auszug:
Inventor 2017.3.1 Update:
123239: Beim Erstellen der Ausschnittansichtstiefe wird das Gewindebohrungselement nicht als Auswahl für Zur Bohrung erkannt
138190: Beim Export einer Stückliste in XLS bleiben keine nachfolgenden Nullen mehr erhalten
158047: Formen-Generator-Browsereinträge können nicht mit einer benutzerdefinierten Materialbibliothek verwendet werden
110617: iProperties-Datum ändert sich, wenn die Systemuhr zur Sommerzeit wechselt
162297: Unerwartetes Beenden beim Aktualisieren von iFeatures
153012: Unerwartetes Beenden beim Exportieren von IDW in DXF
165088: Beschädigte Splines, deren Länge nicht Null ist, werden nicht für den Export angezeigt
166340: Durch das inkorrekte Ausführen eines Makros wird die Datei als fehlerhaft markiert
162614: Beim Exportieren in PDF wird eine unbeabsichtigte Linie erstellt
56742: ActiveDocument sollte Nothing zurückgeben und das OnActiveWebView-Ereignis sollte auslösen, wenn MyHome aktiv ist
167898: Unerwartetes Beenden beim Messen im Express-Modus
152796: Die von iFeatures nicht unterstützten Objekte werden aus der Auswahl entfernt
137297: Vorgang schlägt beim Speichern von ACAD-DWG-Dateien als Inventor-DWG-Dateien fehl
144300: Schlechte Leistung bei der Schnittansicht von Positions- darstellungen
135027, 123989: Pack and Go berücksichtigt die Option Bibliotheken auslassen nicht
173070: Form- und Lagetoleranzen werden nicht Bohrungs- und Gewindeinfo zugeordnet
157923: Exportierte benutzerdefinierte Parameter und iProperty-Werte stimmen nicht überein
Teil 5 verpasst? Dann erstmal hier weiterlesen!
Im fünften Teil haben wir mit den in der Baugruppe verbauten Dateien beschäftigt und die dazu passenden Zeichnung über den Dateipfad gesucht um sie zu Öffnen und als PDF abzuspeichern. War ein harter Brocken, das Beispiel, oder? Ich hoffe, es sind noch ein paar Leser dabei nach dieser Aktion.
Heute machen wir ein Programm, dass durch alle Dateien einer IAM geht und die Bauteilskizzen (un-)sichtbar schaltet, also so, wie wenn wir in der Datei alle Skizzen sichtbar machen würden. Wir brauchen zum Start also wieder eine Baugruppe als Beispieldatei. Nehmt wieder eine kleine IAM! Dann öffnen wir den VBA-Editor (ALT+F11) und und laden unser Beispiel-VBA-Projekt. Da wir wieder durch alle Dateien einer IAM durchgehen wollen, nutzen wir wieder die selben Definitionen wir in der letzten Programmierung.
Wir haben wieder das Objekt, das die gesamte Baugruppe enthält und das Objekt, das für alle referenzierten Dateien steht. Als nächstes kommt die Variablendefinition für das einzelne referenzierte Dokument sowie sowie die Variable, die die Antwort auf eine Frage speichert und eine boolsche Variable, die wahr (true) oder falsch (false) sein kann.
Bevor wir eine Dialogabfrage einbauen, kümmern wir uns aber erstmal um die eigentliche Programmfunktion. Wir wollen durch alle Dateien in der IAM gehen und sollte es sich um eine IPT handeln, alle Skizzen sichtbar machen. Wir brauchen also wieder unser For Each Schleife aus dem letzten Beispiel.
Die Schleife geht durch alle in der IAM verbaute Dateien und mit denen können wir nun was machen. Wir wollen Skizzen innerhalb von Bauteilen sichtbar machen. Ist das aktuelle oRefDoc eine Baugruppe, dann soll nichts passieren. Zudem verändern wir die Sichtbarkeit der Skizze innerhalb der IPT, d.h. die IPT ändert sich und muss im Anschluss gespeichert werden. Speichern geht aber nur, wenn die Datei verändert werden kann, was z.B. bei Bibliotheksteilen nicht der Fall ist. Wir prüfen also, ob die Datei modifizierbar ist und es sich um eine IPT handelt.
Achtet auch darauf, Einrückungen zu verwenden (TAB-Taste) da macht den Code leichter lesbar. Stellt sich die Frage, wie man darauf kommen soll, das es isModifiable gibt? Eine Möglichkeit ist, in der API-Hilfe zu schauen, die wir bereits angeschaut haben. Dort findet man die verschiedenen Objekt und deren Eigenschaften und Methoden.
Eine ändere Möglichkeit ist, das Objekt im Local-Fenster zu untersuchen, wenn man einen Haltepunkt gesetzt hat. Oft sprechen die Einträge ja für sich.
Das ganze Objektmodell findet ihr in diesem PDF-Dokument. Ich hoffe, ihr habt einen A0-Plotter ;)
Stellt sich nun die Frage, wo wir innerhalb des oRefDoc die Skizzen finden. Die verstecken sich unterhalb von ComponentDefinition.
Es gibt dort einen Eintrag Sketches für alle Skizzen und darunter je Skizze ein Item-Eintrag. Wir müssen also durch diese Items durchlaufen und die Eigenschaft Visible = True setzen. Das ist also wieder eine For Each Schleife.
Wir definieren noch eine Variable oSketch als planare Skizze (es gibt ja auch 3D Skizzen) und durchlaufen alle Skizzen innerhalb des oRefDoc und machen sie sichtbar.
Der Quelltext bis zu diesem Punkt:
Das Programm sollte bis dahin funktionieren und in einer IAM bei den IPTs die Skizzen sichtbar machen.
Jetzt ergänzen wir eine Abfrage, ob die Skizzen sichtbar oder unsichtbar gemacht werden sollen.Die Auswahl speichern wir in der Variable Antwort und entsprechend wird die boolsche variable wfBoolean gesetzt.
Jetzt müssen noch dafür sorgen, dass die Skizzensichtbar nicht = True sondern gleich dem Wert der Variable wfBoolean gesetzt wird.
Da die grafische Ansicht nicht aktualisiert wird, machen wir am Ende ein oAsmDoc.Update.
Unser Programm sollte jetzt funktionieren. Je nach dem, ob wir in der Dialogbox Ja oder Nein anklicken. werden alle Skizzen sichtbar oder unsichtbar gemacht.
Unser Programm in voller Pracht:
Der Code in Textform:
Public Sub SkizzeUnsichtbar1() Dim oAsmDoc As AssemblyDocument Set oAsmDoc = ThisApplication.ActiveEditDocument Dim oRefDocs As DocumentsEnumerator Set oRefDocs = oAsmDoc.AllReferencedDocuments Dim oRefDoc As Document Dim Antwort Dim wfBoolean As Boolean wfBoolean = False Antwort = MsgBox("Alle Skizzen Sichtbar (Ja) oder Unsichtbar (Nein)", vbYesNo) If Antwort = vbYes Then wfBoolean = True If Antwort = vbCancel Then Exit Sub Dim osketch As PlanarSketch For Each oRefDoc In oRefDocs If oRefDoc.IsModifiable = True And oRefDoc.DocumentType = kPartDocumentObject Then For Each osketch In oRefDoc.ComponentDefinition.Sketches osketch.Visible = wfBoolean Next End If Next oAsmDoc.Update End Sub
Was fehlt, ist immer noch die Fehlerbehandlung und auch eine Möglichkeit mit einer Rückgängigfunktion die gesamte Aktion rückgängig zu machen. Das schauen wir uns das nächste mal an! Bis dahin viel Spaß mit den Programmieren!
Autodesk hat ein Cloudtool, um Flowcharts zuerstellen. Wer es mal probieren will, kann hier sein Glück probieren: https://praxis.autodesk.com/praxis/
(Quelle)
Teil 4 verpasst? Dann geht es hier weiter!
Im vierten Teil haben wir uns mit dem Border-Objekt in einer Zeichnung beschäftigt. Heute soll es um Komponenten in der Baugruppe gehen. Im einfachsten Fall besteht eine Baugruppe aus Bauteile und/oder Unterbaugruppen. Es gibt eine "Besonderheit" die noch wichtig sein wird: In einer Baugruppe können unterschiedliche Dateien verbaut sein, aber auch mehrere gleiche Bauteile. In dieser IAM ist 3 mal die gleiche IPT verbaut.
Wenn es um die Struktur einer Baugruppe geht, muss man die enthaltenen Dateien von den Komponentenvorkommen unterscheiden. Die Baugruppe enthält eine Datei (Die RAM.ipt) aber 3 Komponentenvorkommen der RAM. Das sind 2 unterschiedliche Paar Schuhe wenn es um die Programmierung geht. Möchte ich wissen, welche Dateien in meiner IAM verbaut sind, beziehe ich mich auf die enthaltenen Dateien. Wenn ich wissen will, wie oft ein bestimmtes Bauteil verbaut ist, dann sind die sog. ComponentOccurrences interessant.
Wir wollen heute mit den Enthaltenen Dateien in der Baugruppe etwas anstellen, uns interessiert also nicht, wie oft eine Komponente in der IAM enthalten ist, sondern nur welche Dateien in der IAM stecken.
Los geht es wie immer mit den Start des VBA-Editors (ALT+F11) und dem laden unseres VBA-Projekts. Dann machen wir eine neue Sub namens Baugruppe. Wie letztes mal schon als Public Sub.
Darin definieren wir eine Variable vom Typ AssemblyDocument und befüllen die Variable mit dem aktuellen Dokument in Inventor. Noch ein Haltepunkt (F9) bei End Sub setzen und schon kann die wilde Fahrt los gehen.
In Inventor muss natürlich eine IAM auf sein (Bitte eine kleine IAM nehmen mit max 20 Bauteilen!), sonst bekommen wir beim Start eine Fehlermeldung. Warum weiß der, der den letzten Beitrag gelesen hat :)
Nach dem Start können wir uns im Locals-Fenster beim Halt bei End Sub das oDoc-Objekt anschauen:
oDoc (=die gesamte Baugruppe) hat in sich Eintrag AllReferencedDocuments und weiter unten ReferenceDocuments. Der Unterschied: AllReferencedDocuments = ALLE enthaltenen Dateien auch in allen Unterbaugruppen. ReferenceDocuments = Nur die direkt in der aktuellen IAM enthaltenen Dateien, also die Komponenten der ersten Ebene. Wenn man hinten bei Type schaut, sieht man, das das Unterobjekt AllreferencedDocuments von TypDocumentsEnumerator ist.
Wollen wir auf dieser Objekt zugreifen, legen wir am besten ein Variable diesen Typs an und befüllen sie mit AllReferencedDocuments aus dem aktuellen Document.
Das Objekt oRefDocs enthält eine "Liste" von Items, wobei jedes Item für eine Datei steht, die in der IAM enthalten ist. Hinten bei Typ sieht man, das alle vom Typ "PartDocument" sind, als es sind nur Bauteile, keine Unterbaugruppen. Zudem sehen wir noch die Eigenschaft Count, die die Anzahl anzeigt. in der IAM sind also 15 verschiedene Dateien enthalten. Diese können u.U. öfter verbaut sein. Das erklärt auch die Zahlen unten rechts im Inventorfenster. Es sind 16 Datei geöffnet (Die eine IAM + alle 15 enthaltene Dateien) und 22 Komponenten sind in der IAM enthalten, weil mache Datei en(z.B. die Schrauben) mehrfach verbaut sind.
Jetzt wollen wir durch die Liste der Items gehen und uns die Dateipfade ausgeben lassen. Dafür nutzen wir die For Each Schleifen, was soviel heißt wie "Für jedes "Ding" innerhalb des "Haufen" mache was". Wir gehen also durch die Liste der Item uns machen etwas mit den Item. Jedes item ist ja auch wieder ein Objekt und zwar i.d.R. ein Bauteil oder eine Baugruppe also allgemein vom Typ Document, also definieren wir eine neue Variable die das jeweilige Item enthält und durchlaufen dann die Liste der Items. Der Codeblock sieht wie folgt aus:
Dim oRefDoc As Document
For Each oRefDoc In oRefDocs
Debug.Print oRefDoc.FullFileName
Next
Wir erstellen ein Objekt namens oRefDoc (enthält später ein EINZELNES referenziertes Document, während oRefDocs von weiter oben ALLE referenzierte Dateien der IAM enthält!!). Dann gehen wir durch die Item-Liste im Objekt oRefDocs und weisen dabei bei jedem Durchgang je ein Item des Objekt oRefDoc zu. die Variable oRefDoc enthält also Item 1, dann Item 2 usw. wir wollen den Dateipfad des aktuellen oRefdoc ausgeben und zwar in einem Fenster im VBA-Editor. Dazu nutzen wir Debug.Print wie oben zu sehen. Next springt nach oben und weißt oRefDoc das nächste item zu. Um die Ausgabe von Debug.Print zu sehen, müssen wir das Immediate-Fenster öffnen (View > Immediate Window). Wenn wir das Programm starten, werden über die For Each Schleife alle items durchlaufen und für jedes Item wird die Eigenschaft FullFilename (=Dateipfad) ausgegeben wie unten im Bild zu sehen.
Jetzt ist das schon ein hammergutes Programm :), aber so wirklich den Riesennutzen hat es noch nicht. Wir wollen was wirklich nützliches machen: Wir wollen für jede Datei schauen, ob es eine Zeichnung gleichen Namens gibt und wenn ja diese öffnen, als PDF speichern und wieder die Zeichnung schließen. Was müssen wir alles machen?
Es gibt noch ein Problem: Beim Öffnen der Zeichnung kann es vorkommen, das Inventor eine Dialogbox bringt, ob er irgendwas aktualisieren soll o.ä. Man kann dem Inventor sagen, das er möglichst keine Meldungen ausgeben soll über ThisApplication.SilentOperation = True. Am Ende des Programms muss die Silentoperation wieder auf False gesetzt werden.
Ich habe dieses mal die Beschreibungen als Kommentare in den Programmcode geschrieben:
Das Beispiel, dass wir heute gemacht haben, ist etwas umfangreicher als bisher und ich weiß, das ich euch viel zugemutet habe, aber es ist auch schon durchaus brauchbar für den Alltag. Was noch fehlt, ist das komplette Errorhandling, also das Abfangen von Fehler. Wenn ihr weiter dabei sein wollt, ist es wichtig, wirklich zu verstehen, was jede Programmzeile bedeutet und für was sie gut ist. Bitte nimm dir die Zeit, zu verstehen, was da Zeile für Zeile passiert, sonst wirst du ab heute raus sein! Ab jetzt geht es richtig ab :)
Hier der Programmcode als Text, für den, der zu Faul zum Tippen ist und als Download.
Public Sub Baugruppe()
'Ruhe im Pu** :)
ThisApplication.SilentOperation = True
Dim oDoc As AssemblyDocument
Set oDoc = ThisApplication.ActiveDocument
Dim oRefDocs As DocumentsEnumerator
Set oRefDocs = oDoc.AllReferencedDocuments
Dim oRefDoc As Document
'Var. die den Pfad zur Zeichnung enthält
Dim Zeichnungpfad As String
'Var die die die zu öffnende Zeichnung enthält
Dim oZeichDoc As Document
For Each oRefDoc In oRefDocs
'Wir berücksichtigen nur Zeichnungen, die im gleichen Pfad sind wie die zugehörige Modelldatei
'wir schreiben also den Fullfilename abzüglich der letzten 4 Zeichen
'(also ohne Dateiendung wie .ipt oder .iam) in die Var Zeichnungpfad
'Left heißt schneide den Linken Teil ab und über Len wir die Länge eines Strings ermittelt.
'Left (Hallo,2) würde Ha ergeben.
Zeichnungpfad = Left(oRefDoc.FullFileName, (Len(oRefDoc.FullFileName) - 4))
'Wir machen ein FileSystemobject um zu prüfen, ob die Zeichnung überhaupt als Datei auf der Festplatte existiert.
'Wie kommt man auf sowas? Man googelt z.B. nach "VBA prüfen ob Datei existiert" oder sowas :)
Dim objFso As Object
Set objFso = CreateObject("Scripting.FileSystemObject")
'Mit dem FileSystemobject und dessen Funktion FileExists prüfen wir, ob die Datei deren Pfad sich aus
'der Var Zeichnungpfad und der Dateiendung .dwg (ODER IDW, WENN IHR IDW NUTZT. ENTSPRECHEND ANPASSEN!)
If objFso.FileExists(Zeichnungpfad & ".dwg") Then
'Die Datei existiert wnen wir hier laden und wir ändern den Inhalt der Var Zeichnungpfad indem wir
'die Endung ergänzen.
'Das ist nicht zwingend notwendig, aber so sparen wir uns das andauerende Anhängen von & ".dwg"
Zeichnungpfad = Zeichnungpfad & ".dwg"
'Jetzt öffnen wir die Zeichnung und weißen die geöffnete Datei dem Objekt oZeichDoc zu.
'Ich denke, der Ausdruck ist soweit klar. Das True am Ende besagt, das die Datei sichtbar geöffnet wird.
Set oZeichDoc = ThisApplication.Documents.Open(Zeichnungpfad, True)
'das hatten wir schon. Wir machen Kopie speichern unter mit der Zeichnung.
Call oZeichDoc.SaveAs(oZeichDoc.FullFileName & ".pdf", True)
'Jetzt die Zeichnung speichern und schließen
Call oZeichDoc.Close(False)
End If
Next
'Inventor darf wieder Dialoge anzeigen
ThisApplication.SilentOperation = False
End Sub
|
|
