Zitat:
Original erstellt von Eugen Jakimenko:
kann mir jemand bei einem Lisp weiterhelfen.
Ja.
Damit wäre Deine Frage beantwortet! 😃
spässle!
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
Erst mal 2 kleinere generelle Dinge
- Speichere Deine LISP files mit dem Encoding UTF-8-BOM (Betonung auf BOM). Dann hat sie eine Markierung und alle aktuellen Programme die Text files lesen können damit umgehen.
Dann funktioniert das auch mit den deutschen Umlauten sauber.
- So hard codierte Dinge wie der Pfadname sind selbst bei test code immer etwas ... hmmm . Ob du in 2 Jahren noch weist ..
definiere im oberen Bereich deines Files lieber eine Variable dafür
Code:
(defvar *init-dir* "C:/Users/Eugen/Desktop/KONSTRUKTION/LISP/Kuehlung-1/Temp-Bohrungen") ; hard coded
(defvar *init-dir* (directory-namestring *load-truename*)) ;; cool . da wo die LISP Datei liegt
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
Im Gegensatz zu den IKIT Funktionen sd-db-element-load und sd-uwgm-element-load liefern die Dialoge im FileMenu keine Sel-Items als return Werte wenn man was lädt.
Deswegen hat man erst mal das Gefühl in der Luft zu hängen. ABER: wir können uns drauf verlassen, das die Objekte,die geladen werden unter :root landen (weil, woher sollte Modeling wissen wo die Objekte in die ModelStruktur einsortiert werden sollten).
Das machen wir uns unter dem Stichwort difference-Bildung zu nutze: also vorher-nachher-waskamdazu?
Code:
(setq obj-root (sd-pathname-to-obj "/"))
(setq objs-before (sd-inq-obj-children obj-root))
;; (pprint (mapcar 'sd-inq-obj-pathname objs-before))
(sd-call-cmds (step_import ....))
(setq objs-after (sd-inq-obj-children obj-root))
;; (pprint (mapcar 'sd-inq-obj-pathname objs-after))
(setq objs-new (set-difference objs-after objs-before :test 'equal))
;; (pprint (mapcar 'sd-inq-obj-pathname objs-new))
Wenn objs-new NIL ist, ist. z.B. was gehörig schief gelaufen.
Die neuen Objekte musst du dann untersuchen. Und JA, ich spreche hier vom Plural. Bei PKG, Bundle, STEP files können das nemmlich meherererere sein!
Deswegen durchnudelt man die Liste der neuen Objekte (plural!)!
In deinem Fall würde ich es grob so machen
Code:
(dolist (new-obj objs-new)
(cond
((sd-inq-assembly-p new-obj) (pprint new-obj);; weiter untersuchen
)
((sd-inq-part-p new-obj) (setq *nippel_test_75_nippel* new-obj) ;;; hurra!
)
(T (pprint "uppssss da lief was anders als erwartet"))
))
Und dann würde ich mit *nippel_test_75_nippel* als sel-item weiter arbeiten. Nicht mit current-part rum-werkeln.
Du wirst sehen das du dich um den ersten Fall 'kümmern' musst, denn STEP import macht immer ein assembly (mit dem Dateiname als Obj_name) und darunter liegen die importieren Objekte.
Noch paar Stolperer:
- im after-input von LOAD_NIPPEL ein (when LOAD_NIPPEL ...) zu nutzen ist sinnfrei.
- im after-input von LOAD_NIPPEL würde ich *nippel_test_75_nippel* am Anfang auf NIL setzen, macht es klarer
- im after-input von LOAD_NIPPEL solltest du bei dem sd-call-cmds (load .. ) mit :failure und :success Form arbeiten
-- zum Testen aktuell mal mutwillig ein PKG file statt einem STP file auswählen, oder nen LSP file .. ;-)
Für Produktive Code sollte *nippel_test_75_nippel* keine globale variable sein, sondern eine Dialog-variable.
Aber noch ist es ja Entwicklungs-Code.
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
Meine Persönliche Meinung: ich tendiere dazu current-part, current-viewset, current-wp usw. NICHT programmatisch zu verändern!
Aus meiner sich sollte der Anwender die Hoheit darüber behalten was 'current' ist.
Wenn ich es doch mal verändere im Code: dann merke ich mir bei dialog-start das aktuelle und in der cleanup-action stelle ich das dann wieder eher.
Wenn Dein/Euer GesamtKonzept natürlich mit dem geladenem Ding noch mehr gemacht werden soll, dann eben...
Code:
(sd-call-cmds (current_part *nippel_test_75_nippel*))
------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP