iLogic: Trigger Before Check-In

Autodesk Vault 2025 hat einen neuen Event-Trigger Before Vault Check-In eingeführt, der es erlaubt iLogics vor dem Check-In-Vorgang auszuführen. Siehe: Event Trigger Reference

Die ursprüngliche Bitte an Autodesk einen solchen Trigger einzuführen, stammt bereits aus dem Jahr 2015. Die Gründe sind nachvollziehbar, da vor diesem Trigger lediglich ein wirklich brauchbarer Event vorhanden war, um effektiv iLogics laufen zu lassen und zwar Before Save Document. iLogics bei jedem Speichervorgang laufen zu lassen ist und war nie wirklich zielführend. Insbesondere, wenn man eine große Menge an iLogics aktiv an die User ausgerollt hat, können diese die Dauer des Speichervorgangs spürbar beeinträchtigen. Viele iLogics kontrollieren, korrigieren oder setzen Property-Werte und oftmals ist es ausreichend dies nicht bei jedem Speichern erfolgen zu lassen, denn ein einmaliger Lauf vor dem Check-In in die Vault Datenbank führt zu selbigem Ergebnis.

Tücken des Triggers

Kurz nach den ersten Testvorgängen, stellte sich schnell Ernüchterung auf meiner Seite ein. Es ist relativ schnell und einfach möglich mit diesem neuen Trigger ein Dokument zu erzeugen, dass sich nicht mehr in Vault einchecken lässt. Ich hatte bspw. einen Fall in der alten iLogic Codebase, der nicht länger benötigte Custom Properties bereinigt hat, wie in diesem Post iLogic: Alte Properties automatisiert löschen beschrieben. Zeitgleich hat eine andere iLogic aber ein eben bereinigtes Property erneut in das Dokument geschrieben. Ersteres geschah beim Speichervorgang. Zweiteres beim Einchecken.

Das Resultat: Zirkellogik und ein Dokument, das nie aktuell ist und sich daher auch nicht sauber in Vault einchecken lässt:

Da scheinbar mehrere User über dieses Problem gestolpert sind, hat Autodesk bereits ein eigenes Support-Dokument veröffentlicht: The file was modified by a rule that ran on check-in

Dort wird die Ursache des Problems wie folgt beschrieben:

When using trigger “Before Vault Check-In” or “After Save Document”, it is not allowed to change (the already saved) Inventor file. Writing properties or any other information in the current file is not allowed for these triggers as it causes that the file needs a save operation again.

Das Kernproblem, welches an dieser Stelle entsteht, ist mangelnde Verbosity, denn die Aussage, dass die Datei während des Check-Ins modifiziert wurde, ist schlichtweg unpräzise und liefert keinerlei Hilfestellungen zur Lösung des Problems. Welche Regel das Dokument modifiziert hat oder was überhaupt modifiziert wurde ist nicht klar ersichtlich. Wer einen guten Überblick über seinen iLogic Code hat und diesen bis ins Detail kennt, mag darin kein Problem sehen. Wer aber eine komplett undokumentierte und unstrukturierte Codebase von 2800 Zeilen Code übernimmt, muss man dann erst mal Haare raufen und sich auf die Suche der Ursache begeben.

Anwendungsfälle für den Trigger

Wie bereits erwähnt, kann der Trigger bei Dokumentenmodifikation zu Problemen führen. Daraus folgt aber auch, dass alle iLogic Tasks, die das Dokument nicht modifizieren, als idealer Anwendungsfall dienen. An dieser Stelle möchte ich zwei reale Anwendungsfälle aufzeigen, die nicht mit dem aktiven Dokument arbeiten, sondern lediglich die Inventor Anwendung per iLogic ansprechen:

FALL 1 - 3D Bauteile in Iso-Ansicht schwenken

Für Bauteile und Baugruppen kann über den Trigger sichergestellt werden, dass das Modell vor dem Einchecken immer in die isometrische Ansicht gedreht wird. Somit findet jeder, der das Dokument aus Vault öffnet dieses einheitlich in identischer Ansicht vor.

FALL 2 - Erste Seite einer Zeichnung aktivieren

Für Zeichnungen kann der Trigger genutzt werden, um vor dem Einchecken die erste Seite der Zeichnung zu aktivieren. Dies sorgt ebenfalls für ein einheitliches Öffnungsverhalten beim Laden aus Vault und sorgt zusätzlich dafür, dass die erste Seite als Thumbnail in Vault hinterlegt wird.

Beide Fälle werden im Folgetext mit Code-Beispielen erläutert.

Isometrische Ansicht für 3D-Bauteile

Um die Inventor Anwendung mittels iLogic zu überreden die aktive Ansicht in die Iso-Ansicht zu schwenken, muss als erstes auf das Camera Object zurückgegriffen werden. Dieses definiert die Ansicht des Modells in der Inventor Application. Das Camera Object hat ein Property namens Camera.ViewOrientationType, mit dem eine spezifische Ansicht gewählt werden kann. Für letzteres ist dann der ViewOrientationTypeEnum wichtig. Der ViewOrientationTypeEnum stellt Standard-Asichten, wie die Vorderansicht, Seitenansicht etc., zur Verfügung, die dem Inventor-Anwender auch vom ViewCube bekannt sein sollten. Er stellt aber auch spezifischere Ansichten bereit, bspw. Blechansichten oder aber die gewünschten Iso-Ansichten:

Im folgenden Beispiel wird der ViewOrientationTypeEnum mit dem Wert kIsoTopRightViewOrientation genutzt:

Private Sub SetIsoView3d()
    Dim oApp As Application = ThisApplication

    Select Case oApp.ActiveDocument.DocumentType

        ' Nur in Bauteilen und Baugruppen ausführen
        Case DocumentTypeEnum.kPartDocumentObject, DocumentTypeEnum.kAssemblyDocumentObject
            Dim oCamera As Camera = oApp.ActiveView.Camera

            ' Schwenke in Iso Ansicht (Top Right)
            oCamera.ViewOrientationType = ViewOrientationTypeEnum.kIsoTopRightViewOrientation
            oCamera.Apply()
            ' View auf aktuelle Fenstergröße anpassen
            oApp.ActiveView.Fit()
    End Select
End Sub

Das Resultat:

Seite 1 aktivieren für Zeichnungen

Für Zeichnungen ist das aktivieren des ersten Zeichnungsblattes leicht möglich. Man muss lediglich über das Sheets Object das erste Sheet Object (Blatt 1) adressieren und über die Methode Sheet.Activate() aktivieren:

Private Sub ActivateDrawingSheet1()
    Dim oApp As Application = ThisApplication

    Try
        ' Sheet 1 aktivieren
        oApp.ActiveDocument.Sheets.Item(1).Activate()
        ' View auf aktuelle Fenstergröße anpassen
        oApp.ActiveView.Fit()
    Catch
        Logger.Warn("Could not activate Sheet 1")
    End Try
End Sub

Das Resultat: