---

VBADrucken.png

Hallo zusammen,

ich habe das Problem, dass ich ein Schriftfeld erstellt habe und sich die entsprechenden iProperties über iLogic aktualisieren: Allerdings nur beim Speichern, einen besseren Trigger finde ich dort nicht. Es wäre allerdings wichtig, dass die Aktualisierung schon beim Befehl "Drucken" angestoßen wird.

Eine mögliche Lösung die ich gefunden habe seht ihr unten (VBA wäre auch ok, damit kann ich ja dann meine iLogic-Regeln auch noch einbinden). Wollte zum Testen einfach mal eine MessageBox sehen wenn das Drucken angestoßen wird, diese erscheint aber nicht.

Der Code steht in einem Klassenmodul, Bild siehe Anlage.

Hat jemand eine Ahnung an was es liegen könnte?

Danke und Grüße,
Georg

__________________________________________________________________________
Private WithEvents m_InputEvents As UserInputEvents

Private Sub CommandButton1_Click()
    Set m_InputEvents = ThisApplication.CommandManager.UserInputEvents
End Sub

Private Sub m_InputEvents_OnActivateCommand(ByVal CommandName As String, ByVal Context As NameValueMap)
    If ThisApplication.ActiveDocumentType = kDrawingDocumentObject Then
        If CommandName = "AppFilePrintCmd" Then
            Dim oDrawDoc As DrawingDocument
            Set oDrawDoc = ThisApplication.ActiveDocument
            MsgBox ("Hey Ho")
            'oDrawDoc.PropertySets.Item("Inventor User Defined Properties").Item("PrintDate").Value = Format(Now, "H:M:S")
            oDrawDoc.Update
        End If
    End If
End Sub
____________________________________________________________

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

---

Das Problem könnte sein, dass Du einen aktiven "VBA-Prozess" brauchst, der auf das Event lauscht (z.B. eine modeless UserForm, die geöffnet ist). Wie hast Du das in Deinem Test gemacht?

Der Wunsch erscheint mir auch etwas aufwändig. Ist es denkbar, die Aktualisierung auch (zusätzlich) beim Öffnen der Zg. zu machen? (oder ist die iLogic-Regel zeitintensiv?)

Alternativ könnte man sich einen eigenen Druck-Befehl bauen (mit VBA) und auf die Benutzeroberfläche legen. Darin nur speichern (evtl. nach einer Abfrage), damit der Trigger für die iLogic anspringt, und anschließend den Drucken-Befehl aufrufen.

------------------
Gruß KraBBy

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

---

Hab vergessen zu erwähnen, dass es mit einem AddIn möglich sein sollte, auf Events zu lauschen.
Die laufen wohl "dauernd" mit IV mit.

Damit kenne ich mich aber nicht aus, ist im Grunde nur "Höhrensagen".
(ich vermute, dass die AddIns von Vault o.ä. so funktionieren und z.B. den IV-Speichern-Befehl kapern/entführen, um ihrer eigenen Logik zu folgen)

------------------
Gruß KraBBy

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

---

Hallo Georg,
Die Sache mit Events und VBA ist nicht besonders komfortabel.
Wurde erst kürzlich hier diskutiert.

------------------
Grüße
Andreas
etaCAD

[Diese Nachricht wurde von bwr am 23. Nov. 2021 editiert.]

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

---

Hallo,

danke für eure Antworten. Ja, ich hätte wirklich gerne "Drucken" und am besten auch noch "Exportieren" als Auslöser. "Öffnen" ist mir da zu wenig und auch die wenigen Trigger,die iLogic bietet.

Ich bin bei meiner Recherche auch auf Addins gestoßen. Dort wurde aber auch erwähnt, dass die Sache "Drucken"-Event nicht mit Addins zu lösen wäre.  Vielleicht ist das auch veraltet gewesen.. Ich kenn mich mit AddIns noch nicht aus - aber wenn ihr mir jetzt sagt dass mein Fall damit zu lösen wäre, dann arbeite ich mich darin ein..

Viele Grüße,
Georg

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

---

Zur letzten Frage bzgl. AddIn kann ich nichts sagen. Ich bin skeptisch, ob das Vorhaben sinnvoll ist. Das kann liegt aber wohl an meiner Unkenntnis von AddIns und könnte durchaus unbegründet sein.
Mein Ansatz wäre es, möglichst nahe bei vorhandenen Möglichkeiten zu bleiben, bevor der Programmieraufwand zu sehr ausartet. Solche Sonderlösungen wollen ja am Ende auch gewartet werden, etc.

Das Problem ist doch, dass die iProperties (iP) geändert werden könnten, während die zugehörige Zg. bereits geöffnet ist. Dann wären die iP der Zg. nicht aktuell. (Sollte die Zg. nicht geöffnet sein, greift mein Vorschlag mit "nach Öffnen von Dokument" um die iP zu sync. bevor die Zg. gedruckt wird o.ä.)

Es gibt den Ereignisauslöser "iProperty-Änderung". Dazu könnte ich mir eine Regel vorstellen, die in den geöffneten Dokumenten nach Zg. sucht, die das aktuelle Modell referenzieren. Wird so eine Zg. gefunden, kann man darin die "Sync.-Regel" starten.

------------------
Gruß KraBBy

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

---

Hallo

@KraBBy
Er will das Druckdatum einfügen. Das geht nunmal nur direkt beim Drucken. Außer man schreibt das bei jedem Öffnen neu und definiert, das es nur in der gedruckten Variante gültig ist, aber nicht in der IDW. Es bleibt immer noch das Problem, das Inventor dann jedes Mal speichern will.

@Darkrondo
Ein OnPrint Event gibt es nicht. Man muss das OnActivateCommand Event belauschen und schauen ob der CommandName für's Drucken "AppFilePrintCmd" ist. Näher kommt man nicht ran. Sollte aber eigentlich reichen.
Ob einem der Aufwand für ein Addin zu groß ist, muss jeder selbst entscheiden. Ein Event abfangen und ein iProp schreiben ist recht überschaubar.

------------------
MfG
Ralf

RKW Solutions GmbH
www.RKW-Solutions.com

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

---

Hallo,

ich kann rkauskh nur bestätigen. Ein entsrechends onPrintEvent gibt es nicht. Man kann nur den entsrechenden Command abfangen und darauf entsprechend reagieren. Solch ein Addin ist nicht besonders komplex und ich würde mich nicht davor fürchten. Ich habe aber vermutlich auch andere Voraussetungen.
Eine Alternative wäre evt. ein Druck-Makro mit dem deine Kollegen die Zeichnungen ausdrucken. Darin kann man dann noch ein paar Zeilen Code einbauen, die sich um das Druckdatum kümmern. Hier ist ein Ansatz, der bei mir verwendet wird. Da habe ich ein paar Schalter in die Benutzerbefehle gemacht und seitdem druckt keiner mehr über den Inventor-Druck-Dialog.

Code:

---

Public Sub DruckenHP_A3()
    ' hier Druckername wie iin Windows bei den Geräten angeben
    Call Drucken("HP LaserJet 5200 PCL 6", kPaperSizeA3, kPaperSizeA3)
End Sub

Public Sub DruckenHP_A4()
    Call Drucken("HP LaserJet 5200 PCL 6", kPaperSizeA3, kPaperSizeA4)
End Sub

Private Sub Drucken(sPrinterName As String, maxPaperSize As PaperSizeEnum, PaperSize As PaperSizeEnum)
    'Print all sheets in drawing document
    'Get the active document and check whether it's drawing document
    If ThisApplication.ActiveDocument.DocumentType = kDrawingDocumentObject Then
   
        Dim oDrgDoc As DrawingDocument
        Set oDrgDoc = ThisApplication.ActiveDocument
   
        ' Set reference to drawing print manager
        ' DrawingPrintManager has more options than PrintManager
        ' as it's specific to drawing document
        Dim oDrgPrintMgr As DrawingPrintManager
        Set oDrgPrintMgr = oDrgDoc.PrintManager
        ' Set the printer name
        ' comment this line to use default printer or assign another one
        oDrgPrintMgr.Printer = sPrinterName
   
        oDrgPrintMgr.PrintRange = kPrintCurrentSheet
        'Set the paper size
        'PaperSizeEnum  A0 9993
        '              A1 9994
        '              A2 9995
        '              A3 9996
        '              A4 9997
       
        On Error Resume Next
       
        If PaperSize > maxPaperSize Then
            oDrgPrintMgr.PaperSize = PaperSize
        Else
            oDrgPrintMgr.PaperSize = maxPaperSize
        End If
       
        'ist Zeichnungsformat größer als gew. Blattformat
        If oDrgDoc.ActiveSheet.Size < oDrgPrintMgr.PaperSize Then
            oDrgPrintMgr.ScaleMode = kPrintBestFitScale
        ElseIf oDrgDoc.ActiveSheet.Size = oDrgPrintMgr.PaperSize Then
            oDrgPrintMgr.ScaleMode = kPrintCustomScale
            oDrgPrintMgr.[Scale] = 1
        Else: Debug.Print "ungültiges Papierformat"
        End If
       
        oDrgPrintMgr.AllColorsAsBlack = True
        oDrgPrintMgr.Rotate90Degrees = False
        oDrgPrintMgr.RemoveLineWeights = False
       
        'Set the paper orientation
        On Error Resume Next
        Select Case oDrgDoc.ActiveSheet.Orientation
            Case kLandscapePageOrientation
                oDrgPrintMgr.Orientation = kLandscapeOrientation
            Case kPortraitPageOrientation
                oDrgPrintMgr.Orientation = kPortraitOrientation
            Case Else    ' Andere Werte.
                Debug.Print "ungültige Orientierung"
        End Select
        oDrgPrintMgr.SubmitPrint
    End If
End Sub

---

------------------
Grüße
Andreas
etaCAD

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

---

Hallo Andreas,

an die Möglichkeit, einen eigenen Button zu erstellen hatte ich auch schon gedacht. Aber anders wäre es mir lieber, denn ich habe die Erfahrung gemacht dass Benutzeroberflächen sehr gerne mal verloren gehen :-( Aber ich merke mir das trotzdem vor, falls ich es anders nicht hinbekomme.

Was das "Event lauschen" betrifft:

Sollte nicht eigentlich nicht dieser VBA-Code, den ich anfangs gepostet habe, schon funktionsfähig sein? Was fehlt mir hier noch? Könnte das evtl jemand ausprobieren?

__________________________________________________________________________
Private WithEvents m_InputEvents As UserInputEvents

Private Sub CommandButton1_Click()
    Set m_InputEvents = ThisApplication.CommandManager.UserInputEvents
End Sub

Private Sub m_InputEvents_OnActivateCommand(ByVal CommandName As String, ByVal Context As NameValueMap)
    If ThisApplication.ActiveDocumentType = kDrawingDocumentObject Then
        If CommandName = "AppFilePrintCmd" Then
            Dim oDrawDoc As DrawingDocument
            Set oDrawDoc = ThisApplication.ActiveDocument
            MsgBox ("Hey Ho")
            'oDrawDoc.PropertySets.Item("Inventor User Defined Properties").Item("PrintDate").Value = Format(Now, "H:M:S")
            oDrawDoc.Update
        End If
    End If
End Sub
____________________________________________________________

Danke, Georg

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

---

Hallo

Probiert, geht.
- UserForm1 erstellt und CommandButton1 eingefügt
- UserForm1.ShowModal=False gesetzt
- Code eingefügt
- UserForm1 gestartet und CommandButon1 angeklickt
- Drucken Befehl angeklickt

--> Messagebox erscheint

Dein Fehler wird vermutlich sein, das deine Form modal läuft. Hatte KraBBy dir aber eigentlich auch schon vor Tagen so gesagt.

Zitat:

---

Das Problem könnte sein, dass Du einen aktiven "VBA-Prozess" brauchst, der auf das Event lauscht (z.B. eine modeless UserForm, die geöffnet ist). Wie hast Du das in Deinem Test gemacht?

---

------------------
MfG
Ralf

RKW Solutions GmbH
www.RKW-Solutions.com

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

---

Hallo zusammen,

vielen Dank für euren Input! Sorry, dass ich nicht darauf eingegangen bin: Die Form war nicht im Modal-Modus. Es geht trotzdem nicht: Ich schaffe es nicht, die Message-Box "Step 2" erscheinen zu lassen.

Ich habe das Gefühl die Lösung ist zum Greifen nah, aber ich komm nicht ganz drauf:

1. UserForm starten:

Sub Form_starten()
UserForm1.Show
End Sub

2. Button-Code in der Form (ShowModal = false):

Private Sub Lauschen_starten_Click()
MsgBox ("Step 1")
Set m_InputEvents = ThisApplication.CommandManager.UserInputEvents
End Sub

3. Klassenmodul:

Private WithEvents m_InputEvents As UserInputEvents

Private Sub m_InputEvents_OnActivateCommand(ByVal CommandName As String, ByVal Context As NameValueMap)
    If ThisApplication.ActiveDocumentType = kDrawingDocumentObject Then
   
        If CommandName = "AppFilePrintCmd" Then
            Dim oDrawDoc As DrawingDocument
            Set oDrawDoc = ThisApplication.ActiveDocument
            MsgBox ("Step 2")
            oDrawDoc.Update
        End If
    End If
End Sub

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

---

Ich denke Punkt 3 ist das Problem. Dieser Code gehört nicht in (irgend)ein Klassenmodul sondern in den Codebereich der UserForm.

Ich habe so erfolgreich getestet:
1. Code in einem Modul:

Code:

---

Sub Form_starten()
    UserForm1.Show False
    'alternativ das Property ShowModal der UserForm auf False
End Sub

---

2. Code in der UserForm1

Code:

---

Private WithEvents m_InputEvents As UserInputEvents

Private Sub CommandButton1_Click()
    MsgBox ("Step 1")
    Set m_InputEvents = ThisApplication.CommandManager.UserInputEvents
End Sub

Private Sub m_InputEvents_OnActivateCommand(ByVal CommandName As String, ByVal Context As NameValueMap)
    If ThisApplication.ActiveDocumentType = kDrawingDocumentObject Then
 
        If CommandName = "AppFilePrintCmd" Then
            Dim oDrawDoc As DrawingDocument
            Set oDrawDoc = ThisApplication.ActiveDocument
            MsgBox ("Step 2")
            oDrawDoc.Update
        End If
    End If
End Sub

---

Erklärungsversuch: Das Event braucht ein Klassenmodul (soweit bist Du ja scheinbar schon). Hier im einfachsten Fall habe ich aber die UserForm1 verwendet (eine UserForm ist auch eine (besondere) Klasse). Damit ist keine weitere Klasse nötig.
Alternativ kannst Du auch (d)eine Klasse verwenden. Du musst dann eine Variable vom Typ dieser Klasse im Code des UserForm-Button initialisieren.

Zum Thema UserForm ist eine Klasse:

Code:

---

Sub Form_starten()

    'UserForm1.Show False
   
    Dim oUF As New UserForm1
    Call oUF.Show(False)
    'bei dieser Schreibweise wird etwas deutlicher, dass es sich bei UserForm1 um eine Klasse handelt
End Sub

---

------------------
Gruß KraBBy

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

---

So wie es KraBBy beschrieben hat funktioniert es bei mir einwandfrei.

Der Nachteil ist halt, dass man sich immer darauf verlassen muss, dass das UserForm1 gestartet wird und der Benutzer auch noch auf den Schalter klickt.
Ein Addin läuft immer im Hintergrund mit und lauscht auf die Events. Da muss der Benutzer erst mal nix machen und bekommt von den ganzen Aktionen bestenfalls nichts mit.

------------------
Grüße
Andreas
etaCAD

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

---

Vielen Dank Krabby, das war der Fehler: Hatte den Code außerhalb der UserForm. Jetzt funktioniert das. Ist auch gut, weil man zusätzlich den "Exportieren"-Befehl dort hineinbringen kann - dem Benutzer soll es freistehen, wie er sein PDF erzeugt, es soll sich bei beiden Aktionen das Datum und die Uhrzeit aktualisieren (da geht's bei uns sehr genau, ist vielleicht ungewöhnlich).

Und richtig: Wenn das Auslösung der Event-Überwachung anstatt der UserForm über ein simples "Dokument öffnen" geschehen könnte, dann wäre das noch praktischer. Es wird bei mir sowieso eine iLogic-Regel beim Öffnen des Dokuments gestartet, diese könnte dann gleich das VBA-Makro mitstarten. Gibt es dazu noch eine Idee wie man die Klasse über eine Public Sub anstatt des Buttons ansteuern kann?

Was AddIns erstellen betrifft muss ich erst mal bei komplett 0 anfangen - darum hoffe ich, diesen Code vorerst zum Laufen zum bringen, bis ich mich da eingelesen habe. Eine fertige App für diese Sache finde ich leider nicht..

Danke, Georg

[Diese Nachricht wurde von Darkrondo am 01. Dez. 2021 editiert.]

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

---

Man kann den Code unter CommandButton1_Click verschieben in ein "UserForm_Initialize" oder "..._Activate" und dann den Button1 entfallen lassen. Damit reicht einzig ein Start dieser UserForm, um auf den Drucken-Befehl zu lauschen.

Wenn Du, wie von Dir beschrieben, das Makro (das wiederum die UF startet) durch eine iLogic-Regel und Ereignisauslöser "beim Öffnen" aufrufst, dann gibt es womöglich Probleme durch mehrere Instanzen dieser UF.
Wird eine Zg. geschlossen, dann wird die UF weiterhin ausgeführt. Beim Öffnen einer weiteren Zg. kommt die nächste UF hinzu. Vmtl. wird das Event Drucken jetzt doppelt behandelt (in jeder geöffneten UF).
Der User wäre dafür verantwortlich, die UF in ausreichender Anzahl auch wieder zu schließen. Schließt er auch die letzte UF braucht es doch wieder einen Befehl, die UF manuell zu starten (oder er schließt und öffnet die Zg. erneut).
Das wirkt auf mich alles noch unausgegoren. 

Wäre es denkbar, die UF manuell vom User starten zu lassen (Makro-Befehl auf der Benutzeroberfläche)? Das könnte man als "firmeneigene Toolbox" verkaufen, wenn man einige Befehle dort als Button ablegt (z.B. die pdf-Erstellung).
Der Gedanke ist: der User soll gar nicht ohne diese Toolbox arbeiten wollen. Diese wäre dann den ganzen Tag neben IV geöffnet und könnte die nötigen Funktionalitäten bereitstellen.

------------------
Gruß KraBBy

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

---

Setup_UpdatePrintDateProp.zip

Hallo

Ein Addin zu erstellen, daß beim Aufruf des Drucken-Befehls ein iProperty "PrintDate" in einer IDW erstellt bzw. aktualisiert, dauert ungefähr 20 Minuten. Viel Spaß damit.

------------------
MfG
Ralf

RKW Solutions GmbH
www.RKW-Solutions.com

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

---

Hallo Ralf,
vielen Dank dir, das funktioniert! 

@ Krabby: Es würde mich trotzdem interessieren wie das mit deinem Denkanstoß zu lösen wäre, weil ich schon zu recherchieren begonnen hatte (und mich das sicher auch weiterbringt vom Verständnis her):

Beginnend mit:

Private Sub UserForm_Initialize()

Diese Private Sub befindet sich außerhalb der UserForm (wird sie beim Dokument öffnen automatisch geladen?)
Hierin müsste ich jedoch dann doch die User-Form laden (jedoch nicht anzeigen) und das Klick-Event simulieren:

Load UserForm1
Call UserForm1.Lauschen_starten_Click

Mein Button in der UserForm1 heißt "Lauschen_starten". Dieser Aufruf funktioniert jedoch nicht..

Außerdem ist in der UserForm ja auch noch diese Zeile zu finden, die ich nicht mehr unterzubringen weiß:

Set m_InputEvents = ThisApplication.CommandManager.UserInputEvents

Danke und Grüße,
Georg

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

---

Hallo Georg,

mit Deinem letzten Post komme ich nicht ganz klar, deshalb gehe ich nicht auf alle Fragen ein.

Ausgehend von meinem Code hier, sollte es reichen diese Zeile

Code:

---

Private Sub CommandButton1_Click()

---

zu ändern in

Code:

---

Private Sub UserForm_Initialize()

---

(das heißt, dieses Sub MUSS in den Code der UserForm!)

------------------
Gruß KraBBy

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

---

Hallo Krabby,
ja, das ist es - funktioniert, neben dem Addin von rauksh, auch.
Wenn man nun noch das "Show.Userform1" ersetzt durch "Load.Userform1" dann scheint das ganze im Hintergrund zu agieren..
Danke

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