krunch

Bonjour à tous Je cherche à faire une option de menu personnalisée qui puisse être cochée/décochée pour aciver/désactiver des commande à base de réacteurs, le menu indiquerait l'état avec une coche X. J'ai essayé le DIESEL $(lisp) dans le nom de la commande, mais au delà des getvar (trouvés ici) le lisp n'a pas l'air de marcher (?). Sinon il y aurait (menucmd "groupe.étiquette=~") mais là aussi je sèche : comment on référence une option de menu depuis l'interface _cui ? Qq un sait comment faire ?

Bonjour J'ai repris cette fonction de (gile) pour la mettre au gout du jour (64 bits) ET en ajouter une nouvelle : la possibilité de ré-affecter l'objet d'un champ d'objet (typiquement : polylignes de surfaces), par exemple si il a été supprimé... C'est la commande EditFieldObject : sélection d'un champ d'objet puis d'un objet Pour ça, j'avoue j'ai opté pour une méthode de fainéant : l'ajout d'un argument (le nouvel Id) à la fonction gc:FieldCode de (gile) (sans avoir vraiment pris le temps de la décrypter :huh: ) .. Juste une remarque : avec des textes multilignes CopyFieldFormat copie tout le texte placé après le champ d'objet, ce qui peut être gênant. Sinon (d'après d'autres discussions) le regen final a l'air indispensable avec les références d'attribut (?), dans ces codes j'ai mis un test Voilà, merci à (gile) ; EditFieldObject : Affecte un nouvel objet à un champ d'objet ; Note : affecte tous les champs d'objets des MText (plusieurs champs possibles) ; source entité affectée au champ ; target champ modifié (defun c:EditFieldObject (/ target fieldCode format source acdoc) (vl-load-com) (setq acdoc (vla-get-ActiveDocument (vlax-get-acad-object))) (vla-startundomark acdoc) (and (setq target (nentselp "\nSélectionnez un champ d'objet : ")) (setq target (car target)) (setq format (gc:FieldCode target nil)) ; temporaire pour test si champ d'objet (vl-string-search "ObjId" format) (setq source (car (nentsel "\nSélectionnez le nouvel objet : "))) (setq fieldCode (gc:FieldCode target source)) (setq format (substr fieldCode (1+ (vl-string-search "\\f" fieldCode)))) (setq target (vlax-ename->vla-object target)) (progn (vla-put-TextString target "") (vla-put-TextString target (strcat (substr fieldCode 1 (vl-string-search "\\f" fieldCode)) format)) (if (= (vla-get-objectname target) "AcDbAttribute") (vla-Regen acdoc acActiveViewport)) ) ) (vla-endundomark acdoc) (princ) ) ; CopyFieldFormat (gile) : copie le format d'un champ vers un autre ; source champ source du format à copier ; target champ modifié (defun c:CopyFieldFormat (/ source fieldCode format target acdoc) (vl-load-com) (setq acdoc (vla-get-ActiveDocument (vlax-get-acad-object))) (vla-startundomark acdoc) (and (setq source (car (nentsel "\nSélectionnez le champ source : "))) (setq fieldCode (gc:FieldCode source nil)) (setq format (substr fieldCode (1+ (vl-string-search "\\f" fieldCode)))) (while (setq target (car (nentsel "\nSélectionnez un champ cible : "))) (if (setq fieldCode (gc:FieldCode target nil)) (progn (setq target (vlax-ename->vla-object target)) (vla-put-TextString target "") (vla-put-TextString target (strcat (substr fieldCode 1 (vl-string-search "\\f" fieldCode)) format)) ) ) ) (if (= (vla-get-objectname target) "AcDbAttribute") (vla-Regen acdoc acActiveViewport)) ) (vla-endundomark acdoc) (princ) ) ;; gc:FieldCode (gile) ;; Retourne la chaîne de caractère d'un attribut, texte ou mtexte avec le(s) code(s) de champ(s) ; ent ENAME Nom d'entité de l'objet ; obj ENAME/nil Nouvelle entité à affecter au code de champ(s) d'objet / entité déjà affectée (defun gc:FieldCode (ent obj / foo elst xdict dict field str) ;;--------------------------------------------------------;; (defun foo (field str / pos fldID objID) (setq pos 0) (if (setq pos (vl-string-search "\\_FldIdx " str pos)) ; Itération des champs de str (while (setq pos (vl-string-search "\\_FldIdx " str pos)) (setq fldId (entget (cdr (assoc 360 field))) field (vl-remove (assoc 360 field) field) str (strcat (substr str 1 pos) (if (setq objID (cdr (assoc 331 fldId))) ; champ d'objet (vl-string-subst (strcat "ObjId " (GetObjectID (if obj obj objID))) "ObjIdx" (cdr (assoc 2 fldId))) ; champ d'envrnt (foo fldId (cdr (assoc 2 fldId))) ) (substr str (1+ (vl-string-search ">%" str pos))) ) ) ) str ) ) ;;--------------------------------------------------------;; (setq elst (entget ent)) (if (and (member (cdr (assoc 0 elst)) '("ATTRIB" "MTEXT" "TEXT")) (setq xdict (cdr (assoc 360 elst))) (setq dict (dictsearch xdict "ACAD_FIELD")) (setq field (dictsearch (cdr (assoc -1 dict)) "TEXT")) ) (setq str (foo field (cdr (assoc 2 field)))) ) ) ; Renvoie ObjectID (string) de ent / "" si objet supprimé (defun GetObjectID (ent / div err) (setq ent (if (vl-catch-all-error-p (setq err (vl-catch-all-apply 'vlax-ename->vla-object (list ent)))) nil err)) (if ent (if (vlax-method-applicable-p (vla-get-Utility acdoc) 'GetObjectIdString) (vla-GetObjectIdString (vla-get-Utility acdoc) ent :vlax-false) (itoa (vla-get-ObjectId ent)) ) "" ) )

Merci bien. J'ai beau réessayer : avec Autocad 2008 le résultat est toujours un rectangle déformé (comme mis en perspective et projeté sur le plan SCU) dès que je passe en vue perspective. D'autre part la focale (du moins la variable LENSLENGTH) n'influe pas sur la déformation. Peut-être qu'ils ont changé un truc dans la 2009.. J'ai du mal à le croire, mais comme je ne vois pas d'autre variable concernée...

Bonjour (gile) Tu m'autorises à exporter ma question avec ta routine TEST sur d'autres forums ? (en mentionant le source ?)

Salut En effet, je ne connaissais pas ce filtre (il n'est d'ailleurs pas décrit dans l'aide ssget), et en effet il n'accepte pas d'argument supplémentaire (point) :-( Alors pour filtrer j'utilise la fonction (acet bns_ss_mod), mais ça revient à faire un post-filtrage, sans doute à peine plus rapide qu'une itération..

Dommage qu'on ne puisse pas faire ça pour les objets des calques verrouillés

ReBonjour à tous Ce serait vraiment sympa d'essayer la fonction TEST ci-dessus de (gile) en 3D perspective et de me dire si vous obtenez le résultat escompté (ou comme moi un quadrilatère en perspective) ainsi que votre version.. J'aimerais (tenter de) savoir si c'est une question de version ou autre chose. En vous remerciant

Merci En effet c'est plutôt curieux, et je suppose que ça doit être une question de version car chez moi j'obtiens ça, également avec ta dernière fonction TEST : http://img716.imageshack.us/img716/2138/sanstitre1joh.jpg [Edité le 28/2/2011 par krunch]

Rebonjour Alors d'après cette page (tout en bas) il y aurait bien une déformation (par matrice non-uniforme ?) à faire.. Mais ce que je ne comprends pas c'est où sont les paramètres, car dans une vue 3D conique (par exemple faite avec VUEDYN) les variables LENSLENGTH et PERSPECTIVECLIP n'affectent pas la projection.. Bon, sinon... ça intéresse pas trop la 3D conique ?.. Je suis à deux doigts d'avoir l'impression de parler tout seul ;-(

J'ai refait une tentative mais sans succès.. (nouveau code en dessous, on l'appelle avec (InputSel '(0 0 0)) ) Je rappelle que c'est pour dessiner des lignes avec grvecs dans une vue 3d conique (là ce n'est qu'un exemple...) Et donc dans ce cas (conique) les points interpolés par des opérations dans le SCV [ (trans pnt 1 2) > calcul > (trans pnt 2 1) ] ne sont pas valables. Ce qui est bizarre c'est qu'on dirait que seul les X des variables pt1vue et pt3vue ont besoin d'être corrigés, pas les Y. D'autre part quand je modifie la variable LENSLENGTH la déformation est la même (ce qui voudrait dire qu'elle n'influe pas), et je vois pas trop quel paramètre peut entrer en compte en vue perspective... Si quelqu'un en sait plus là dessus.. (defun InputSel (1st / out gr in pnt sel) (princ "\n> Sélection (2è point) : ") (while (not out) ; donnée du tampon grread : suivant si (5 . ..) / actuel sinon (setq gr (if (= (car (setq gr (grread t 14 2))) 5) (grread t 14 2) gr) in (car gr)) (cond ; in = 3Dpt[sCU] * ROLLOVER ((= in 5) (setq pnt (cadr gr)) (redraw) (DrawQuad 1st pnt) ) ; * CLIC ((= in 3) (print "clic") (setq out T) ) ; * CLIC-DROIT ((= in 25) (setq out T) ) ) ) ) (defun DrawQuad (pt0 pt2 / pt0vue pt2vue pt1vue pt3vue pt1 pt3 ssmode) (setq pt0vue (trans pt0 1 2)) (setq pt2vue (trans pt2 1 2)) (setq pt1vue (list (car pt2vue) (cadr pt0vue) (caddr pt0vue))) (setq pt3vue (list (car pt0vue) (cadr pt2vue) (caddr pt2vue))) (setq pt1 (trans pt1vue 2 1)) (setq pt3 (trans pt3vue 2 1)) (setq ssmode (if (< (car pt2vue) (car pt0vue)) "_CP" "_WP")) (grvecs (list (if (= ssmode "_CP") -255 255) pt0 pt1 pt1 pt2 pt2 pt3 pt3 pt0)) )

Bonjour à tous En général quand je fais des traçages grdraw grvecs et que je passe la vue en 3D conique (le mode perspective à projection non-parallele en passant par l'orbite + clicdroit) ça ne marche plus... La projection fait que les calculs issus de trans ne sont plus valables L'exemple en dessous est un essai de fonction équivalente à celle donnée par gile ici (SelOneOrMore en milieu de page), à savoir une fenêtre de sélection. Le calcul-affichage n'est pas optimisé mais il fait un calcul équivalent à SelOneOrMore (*), en passant par le SCV (trans pnt 1 2) et il affiche une fenêtre de sélection Mais dans les 2 cas (celui là et SelOneOrMore) si je passe en 3Dconique ça ne marche plus : la fenêtre devient un rectangle en pers, seuls les points clés (le 1er et le curseur) sont valables. Il faut faire quelque chose d'autre, peut-être passer par les matrices ? (*) note à gile : il me semble que résultat est le même si la projection est parallèle (mais sans ilp et vxv) ? Appel : (InputSel '(0 0 0)) (defun InputSel (1st / out gr in pnt sel) (setq 1st (trans 1st 1 2)) (princ "\n> Sélection (2è point) : ") (while (not out) ; donnée du tampon grread : suivant si (5 . ..) / actuel sinon (setq gr (if (= (car (setq gr (grread t 14 2))) 5) (grread t 14 2) gr) in (car gr)) (cond ; in = 3Dpt[sCU] * ROLLOVER ((= in 5) (setq pnt (trans (cadr gr) 1 2)) (setq pnt (list 1st (list(car 1st)(cadr pnt)(caddr 1st)) pnt (list(car pnt)(cadr 1st)(caddr pnt)))) (setq pnt (mapcar '(lambda(u) (trans u 2 1)) pnt)) (redraw) (TraceVects pnt T 1 0) ) ; * CLIC-DROIT ((= in 25) (setq out T) ) ) ) ) (defun TraceVects (ptlist cls coul high / X Y) (setq ptlist (mapcar '(lambda (U) (trans U 0 1)) ptlist)) (mapcar '(lambda (X Y) (grdraw X Y coul high)) ptlist (cdr ptlist)) (if cls (grdraw (car ptlist) (last ptlist) coul high)) ) [Edité le 19/2/2011 par krunch]

Ce qui fait la "purgeabilité" c'est d'abord le fait que le bloc n'ait plus de référence insérée dans le dessin. Sinon il est possible d'accéder au niveau le + haut d'un bloc, mais en passant par la RefBloc (en cherchant les parents soit avec OwnerId soit avec le code 330).. Pas sûr que ce soit plus simple Et sinon enfin il y a une fonction (acet-block-purge bna), je ne sais pas ce qu'elle apporte de plus [Edité le 17/2/2011 par krunch]

Bon.. et ici un .xls.. Si jamais pour une raison indue vous ne pouvez vraiment pas installer d'urgence OpenOffice.. (contactez votre administrateur pour résoudre ce problème :)) http://file.ahst.fr/get.php?id=4d41b0688c7f7

Ok j'avais pas assez lu.. voilà le lien : http://file.ahst.fr/get.php?id=4d41aeb96053d C'est un fichier .ods (pour inciter à utiliser OpenOffice :)).. [Edité le 27/1/2011 par krunch]

C'est que pour les images :( Il y a d'autres sites mais je trouve pas là.. D'autre part je disais ça parceque c'est un tableau vide aux 9/10è.. Donc, à moins que quelqu'un se sente de faire 400 essais + description, il a des chances de rester vide à moins d'une bdd qu'on peut alimenter..

Au point que je sais même pas où le mettre mon fichier.. (on peut pas mettre une PJ ici) Sinon je disais "ça pourrait être un truc collaboratif" comme un wiki mais j'y connais rien là dedans :-)

Ben.. y'en a pas : pour l'instant c'est juste un tableau pas fini, une liste complète, mais avec beaucoup de cases à remplir.. ça pourrait être un truc collaboratif mais j'ai pas la technique...

merci.. Si ça intéresse quelqu'un je tiens à jour un fichier de description de ces fonctions (avec ce que j'ai trouvé sur le net + mes essais)..

Bonjour Y a t-il un inconvénient à se servir de ces fonctions (bien utiles) ? En particulier y a t-il un risque pour qu'elles ne soient pas chargées ? Leur localisation (pour chargement éventuel) n'est pas clair du tout... entre les différents fichiers (acetutil.arx ACETAUTO.LSP acetutil.fas acetutil2.fas ...) je n'arrive toujours pas à comprendre qui est où.. Il y a aussi les fonctions acet-init... Bref peut on les utiliser en étant sûr qu'elles sont chargées ? Et sinon comment faire ??

Re-salut C'est tout à fait ça, sauf que ce n'est pas un Move mais un Transformby, et c'est même des Transformby successifs sur une même sélection. Au contraire c'est justement ce que je cherche à accélérer, je ne veux surtout pas passer outre... Bref, la solution est sans doute un peu trop tordue... L'autre piste est la question que j'ai posée ici : http://www.cadxp.com/sujetXForum-31240.htm (comment passer une matrice à une routine vba) Si quelqu'un a une idée là dessus.... En attendant merci pour vos réponses

A la fin la RefBloc est explosée, donc les entités se retrouvent à leur niveau initial Effectivement c'est tordu, mais l'avantage est que je me retrouve avec une commande Lisp plus rapide qu'une commande standard (tu peux essayer c'est impressionnant) Alors qu'avec une itération du jeu de sélection j'ai largement le temps de me faire un café.. (je la teste avec des sélections de 10 à 20 000 objets) C'est bien pour ça que je vous demandais si c'est acceptable ou pas.. Je rectifie : le explode prend un peu de temps, mais l'affichage de la preview (avant explode) est bien + rapide Par ailleurs ce n'est bien sûr pas pour faire une simple _Move, c'est pour faire un outils de transformations paramétrables, une sorte de "_MoveRotateScaleMirror"... [Edité le 20/1/2011 par krunch]

J'utilise (CopyObjects) pour fabriquer une référence de bloc (donc un bloc) à partir de la sélection. Il me semble qu'il n'y a pas d'alternative pour ça ?

D'accord, donc je peux garder (CopyObjects).. Justement j'en sais rien : le but est de faire une commande usuelle, utilisable dans tous les cas de figure. Cette astuce (traitement d'une RefBloc plutôt que d'un jeu de sélection) vaut vraiment le coup d'être exploité.. Alors ma question était générale : finalement est ce que c'est si gênant que ça ?

Ok merci gile, donc il vaudrait mieux utiliser vla-copy.. Je vais regarder ça, mais pour être plus précis la séquence complète est : copie dans un nouveau bloc > insertion > traitement > explode D'où l'utilisation de (CopyObjects).. L'avantage est un temps de traitement incomparablement plus rapide qu'une itération dans un jeu de sélection (avec des énormes sélections bien sûr) : plusieurs centaines de fois plus rapides.. et même, bizarrement, plus rapide qu'avec la commande _Move tout en restant en Lisp !! PS: c'est la raison pour laquelle je posais cette question là : http://www.cadxp.com/sujetXForum-31240.htm [Edité le 20/1/2011 par krunch]

Oui, on est d'accord :-) Bon je reformule... Imaginez une commande usuelle comme _Move par exemple (mais en mieux), qui à chaque utilisation restitue une copie de la sélection initiale (vous vous en rendez compte parce que le handle des entités a changé) : elle a donc copié, déplacé et effacé la sélection... Évidemment ce n'est pas ce qu'on lui demande, même si dans la majorité des cas ce n'est pas très gênant. Mais le fait qu'elle copie est une conséquence de sa structure, c'est comme ça ! Ma question est : est ce que vous gardez quand même cette commande ou est ce que selon vous c'est rédhibitoire ? Il me semble que l'inconvénient vient surtout d'éventuelles données associées (XDatas, réacteurs), et comme elle utilise (CopyObjects) je voulais savoir si il y avait un moyen de garder les données associées. Je me demandais aussi si il y avait d'autres raisons qui feraient que cette particularité est gênante.. Voilà, en espérant être plus clair, merci d'avoir répondu..