Communauté
Salut,
Première chose, déclare tes variables localement, ça t'évitera des erreurs difficiles à localiser.
par exemple, quand tu fais : (setq NomEnt (cons (entlast) NomEnt)), tu ajoutes le ename de la dernière entité créée à une liste. si la variable NomEnt n'est pas déclarée localement (elle est donc globale) la liste reste en mémoire dans le dessin après que ton LISP ait terminé son exécution, et si tu le relance, la liste continuera de se remplir.
De toute façon, l'erreur que je vois vient de là. Dans un premier temps tu affectes à la variable NomEnt un nom d'entité (type ENAME) avec (entlast) puis dans la boucle, tu changes le type de valeur de la variable avec (cons ...) et en fais une liste (type LIST). Ensuite, tu essayes de te servir de te servir de cette variable avec la commande SCU option Objet qui attend un nom d'entité et pas une liste, ce qui devrait immanquablement provoquer une erreur.
Si tu utilises l'éditeur Visual LISP d'AutoCAD, ce que je te recommande fortement, tu peux faire un "pas à pas" soit en évaluant les expressions une par une dans l'éditeur ; soit en plaçant un point d'arrêt dans ton code et en utilisant le "pas à pas" de fonctions de débogage (F8). Ceci te permettra de localiser les erreurs, d'interroger les valeurs de variables et ainsi de corriger tes erreurs.
Je te recommande la lecture du document : Introduction à AutoLISP.
Salut,
Non, ce n'est pas possible avec entnext. si tu appelles la fonction entnext en lui passant une référence de bloc comme argument, la fonction retourne uniquement les référence d'attribut (si le bloc en a).
Il faut bien comprendre qu'une référence de bloc n'est qu'une représentation géométrique de la défintion du bloc. Seule la définition du bloc contient des entités, les références de bloc ne peuvent avoir, comme sous entités, que des références d'attributs.
Il y aurait un moyen avec la fonction nentsel ou plutôt avec nentselp. ces fonctions permettent de retrouver l'entité dans la définition du bloc, mais sa suppose de transformer l'entité de la définiton du bloc (définie dans les coordonnées du bloc) avec la matrice de transformation de la référence de bloc (qui est dans la liste retournée par nentselp). Ceci est assez compliqué en AutoLISP (à moins que tu sois à l'aise en transformations linéaires et calcul matriciel) et à peine plus simple avec les fonctions Visual LISP.
Mais comme tu connais la géométrie de ton bloc, il est certainement plus facile de partir du point d'insertion du bloc et de déterminer la position des sommets du rectangle en fonction de la rotation du bloc et des éventuelles échelles en X et Y (tu trouves tout ça dans la liste DXF du bloc) :
(setq bloc (entlast)
dxfList (entget bloc)
insPt (cdr (assoc 10 dxfList))
scaleX (cdr (assoc 41 dxfLst))
scaleY (cdr (assoc 42 dxfLst))
rotat (cdr (assoc 50 dxfList))
)
Ensuite avec la fonction polar, et les dimensions connues du rectangle dans la définition du bloc c'est assez facile de replacer des points dans l'espace objet.
Par exemple un point qui serait en (12 0 0) dans la défintion du bloc sera en:
(polar insPt rotat (* 12 scaleX))
Un point qui serait en (0 8 0) sera en :
(polar insPt (+ rotat (* pi 2)) (* 8 scaleY))
Salut,
D'après les souvenir que j'ai en DCL, si tu places tes radio_button dans un boxed_radio_column ou un boxed_radio_row, un bouton du conteneur sera coché par défaut (le premier, à moins que tu spécifies la propriété value="1"; pour un autre bouton dans le fichier DCL).
Ceci facilite aussi la façon de récupérer quel bouton a été coché : la propriété value du boxed_radio_column ou du boxed_radio_row contient la clé du radio_button coché.
Vous n'avez pas trouvé ce que vous recherchiez ? Posez une question à la communauté ou partagez vos connaissances.
Publier dans les forums
