| |
| Gut zu wissen: Hilfreiche Tipps und Tricks aus der Praxis prägnant, und auf den Punkt gebracht für NX |
Autor
|
Thema: Part ist modifiziert / user_exit (1465 mal gelesen)
|
romu Mitglied Masch. Ing. HTL
Beiträge: 36 Registriert: 03.03.2003
|
erstellt am: 03. Mrz. 2003 12:08 <-- editieren / zitieren --> Unities abgeben:
UG stellt fest, dass das geladene Part modifiziert wurde. Dies wird dargestellt im AMT mit dem Icon 'modified'. Ist das Part als readonly geöffnet, wird eine Meldung dargestellt mit der Warnung, dass das Part modifiziert wird und nich gespeichert werden kann. Frage : - Ist es möglich an dieser Stelle (Ereignis) eine eigene Applikation (z.B. Grip) aufzurufen??
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
berberic Mitglied Software-Developer
Beiträge: 113 Registriert: 04.02.2003 Don't worry be happy. Michael
|
erstellt am: 06. Mrz. 2003 21:31 <-- editieren / zitieren --> Unities abgeben: Nur für romu
Hallo romu, Ja, mit einem UG/Open-Programm das ist möglich. Du must die Funktion UF_add_callback_function mit UF_modified_part_reason als Callback-Grund verwenden. Innerhalb deiner eigenen Callback- Funktion wirst Du, beim Laden von Parts, über alle geänderten Parts (auch referenzierte Komponenten) benachrichtigt. In deiner Callback-Funktion must Du dann allerdings selbst prüfen, ob die Datei schreibgeschützt ist. Am einfachsten verwendest Du die Funktion UF_PART_ask_part_name in Verbindung mit fopen (part_name,"r++") oder uc4500. Aber Vorsicht, Ableitungen von Teilefamilien sind in UG intern ebenfalls als schreibgeschützt markiert. Hier ist eine Überprüfung mit der Funktion UF_PART_is_family_instance erforderlich. Gruß Michael
------------------ Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Walter Hogger Moderator Maschinenbauingenieur
Beiträge: 3901 Registriert: 06.10.2000 UG V2 bis UG V18 NX1 bis NX2008 ("NX19")
|
erstellt am: 07. Mrz. 2003 10:06 <-- editieren / zitieren --> Unities abgeben: Nur für romu
Hallo romu, hallo berberic, nur der Vollständigkeit halber: Es muss nicht unbedingt User Function sein, es klappt auch mit GRIP. In der Datei "ugii_env.dat" können sogenannte "User Exits" definiert werden. D.h. man sagt UG, immer bevor gespeichert wird soll vorher mein GRIP- oder User Function Programm xyz aufgerufen werden. Solche "Ich-misch-mich-ein-Stellen" gibt es nicht nur beim Speichern, sondern auch beim Plotten, Part Erzeugen, ... Gruss ------------------ Walter Hogger Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
romu Mitglied Masch. Ing. HTL
Beiträge: 36 Registriert: 03.03.2003
|
erstellt am: 07. Mrz. 2003 13:01 <-- editieren / zitieren --> Unities abgeben:
Hallo Walter Die User_exits kenne ich und hab ich bereits versucht zu verwenden. Leider gibt es aber kein User_exit an der Stelle wo das System bemerkt, dass das geöffnete Part modifiziert wurde. Ich möchte eine Sperrung am nativen File vornehmen, sobald das Part modifiziert wird. Eine Idee war folgende: sobald in der Baugruppe mit Change Work Part in ein Einzelteil gewechselt wird, soll das zu öffnende Einzelteil gesperrt werden mit dem user_exit 'USER_CWORK'. Das Problem ist aber, dass das user_exit 'USER_CWORK' mein Grip-Programm aufruft bevor in das Part gewechselt wird. Mein Grip-Programm (&PNAME) erhält dann keine Information in welches Part gewechselt wird sondern gibt immer noch den Namen der Baugruppe zurück. Daher suche ich nun die Möglichkeit auf das Ereignis zu reagieren wenn am Part selbst modifiziert wird ..... Vielleicht gibt es noch eine anderen Weg.... aber wie ?? Danke trotzdem¨
Gruss romu ------------------ Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
berberic Mitglied Software-Developer
Beiträge: 113 Registriert: 04.02.2003 Don't worry be happy. Michael
|
erstellt am: 09. Mrz. 2003 20:40 <-- editieren / zitieren --> Unities abgeben: Nur für romu
Hallo romu, Hallo Walter, User-Exits können sowohl GRIP als auch UG/Open-Programme sein. Ein User Exit wird aber nur aufgerufen, nachdem eine bestimmte Benutzeraktion angefordert wurde (z.B. Open Part) und bevor diese von UG ausgeführt wird. Sie sind eigentlich dafür vorgesehen, die Standard UG-Dialoge durch eigene zu ersetzen. Deshalb kann UG innerhalb des User-Exits auch keine entsprechenden Informationen liefern. Die mit der UG/Open UF_add_callback_function eingebunden Callback- Funktionen werden, bis auf eine Ausnahme, erst nach Ausführung der entsprechenden Aktion aufgerufen, sodass dann auch die entsprechenden Informationen abrufbar sind (s.a. Beispielprogramm im Anhang). Also entweder User-Exit 'USER_CWORK' verwenden, wobei Du den Dialog für die Partauswahl, in Grip oder UG/Open selbst implementieren müsstest. Alternativ UG/Open-Funktion UF_add_callback_function mit UF_change_work_part_reason als Callback-Grund verwenden. Du bekommst innerhalb Deiner Callback-Funktion das Tag des neuen Work-Parts übergeben. Der Rest ist wohl nur noch ein Klacks. Entscheidet selbst was sinnvoller macht. Gruß Michael ------------------ Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
romu Mitglied Masch. Ing. HTL
Beiträge: 36 Registriert: 03.03.2003
|
erstellt am: 20. Mrz. 2003 11:10 <-- editieren / zitieren --> Unities abgeben:
Hallo Michael Hallo Walter Habe nun nach einigen Startschwierigkeiten mit Erstellen von Projekten in der C++.NET Version es doch noch hingekriegt (bin eben ein C-Anfänger). Der C-Programmcode von Michael macht eigentlich genau das wonach ich gesucht habe. Die Sache mit den Grip-Programmen und UserExits kann ich daher nicht gebrauchen, da es kein User_exit gibt, welches auf Ereignis 'Part wird modifiziert' reagiert. Ich werde nun auf der Basis des C-Programms von Michael versuchen meine Aufgaben zu lösen. Mein Hauptanliegen besteht ja nach wie vor darin einen Mechanismus herzustellen, welcher eine Sperrung am Part vornimmt, wenn dieses geändert wird. Eine weitere Anforderung ergibt sich nun daraus: Da ich die VBA-Programme bereits erstellt habe, welche ein geändertes Part sperren, versuche ich nun eine Applikation aus dem C-Programm von Michael zu starten. Der Versuch mit der C-Funktion 'WinExec' funktioniert. Leider wartet WinExec aber nicht auf die Abarbeitung meiner VBA-Applikation. Die Funktion 'CreateProcess' ist anscheinend diejenige, welche hier zu Anwenung kommen soll. Leider habe ich diese aber nicht zum funktionieren gebracht, da sie tonnenweise Parameter aufweist. Meine VBA-Anwendung erwartet die Parameter 'p=partname u=user' und wird eine Parameter zurückgeben der besagt ob das Part geändert werden kann oder nicht. Kennt jemand CreateProcess ??? Habe zwar Beispiele gefunden auf dem Internet aber ohne Erklärung welche ich verstehe, vorallem ohne Erklärung über die vielen Parameter. Gruss romu ------------------
[Diese Nachricht wurde von romu am 20. März 2003 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
berberic Mitglied Software-Developer
Beiträge: 113 Registriert: 04.02.2003 Don't worry be happy. Michael
|
erstellt am: 24. Mrz. 2003 21:18 <-- editieren / zitieren --> Unities abgeben: Nur für romu
|
romu Mitglied Masch. Ing. HTL
Beiträge: 36 Registriert: 03.03.2003
|
erstellt am: 24. Mrz. 2003 22:48 <-- editieren / zitieren --> Unities abgeben:
Hallo Michael Hab gedacht, dass dieser Einwand kommt. Die Antwort ist ganz einfach: Habe die Sache bereits in VBA programmiert und bin in ugopen noch sehr unerfahren als dass ich das auf die schnelle hinkrieg. Ich werde das bestimmt aber eines Tages tun. Gruss Rolf
------------------ Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Thomas Röhrig Mitglied
Beiträge: 189 Registriert: 14.07.2001
|
erstellt am: 25. Mrz. 2003 11:53 <-- editieren / zitieren --> Unities abgeben: Nur für romu
|