Matt666 Posté(e) le 21 décembre 2018 Posté(e) le 21 décembre 2018 Bonjour à tous, Ca faisait longtemps.J'ai un petit problème en lisp, qui révèle sans doute mon manque de compréhension de la base de données des entités sur AutoCAD (sur BricsCAD pour ma part, ce qui est plus ou moins similaire). je ne sais pas si c'est pareil pour vous, mais il existe une différence d'e-name d'entité imbriquée dans un bloc, en fonction de la méthode de sélection :Si le bloc n'est pas en édition, (car (nentsel))Si le bloc de l'entité est en édition par la commande refedit. (car (entsel))La variable refeditname peut nous apprendre si un bloc est édité ou pas. Ci-dessous un petit test qui balaye toutes les entités imbriquées et retourne "Ok" si l'e-name est présent :(defun test (e / i d) (while (setq i (tblnext "BLOCK" (null i))) (setq d (cdr (assoc -2 i))) (while d (if (eq e d) (princ "\nOk !") ) (setq d (entnext d)) ) ) (princ) ) Si on passe par un (test (car (nentsel))), l'entité est trouvée.Si on passe par un refedit + (test (car (entsel))), la routine ne trouve pas l'e-name !Avez-vous déjà eu ce pb ? Voyez-vous de quoi je parle ?Y a t-il une solution ?Merci !Matt. "Chacun compte pour un, et nul ne compte pour plus d'un."
Patrick_35 Posté(e) le 21 décembre 2018 Posté(e) le 21 décembre 2018 Salut Oui, c'est exact. Je n'avais jamais remarqué et ce n'est pas logique.On sélectionne un bloc, puis modifbloc et on note l'ename d'un objet. On sort de l'éditeur.On sélectionne un autre bloc (mais le même nom que le précédent, juste une autre insertion), puis modifbloc, on regarde l'ename du même objet qu'auparavant, et ce n'est pas le même... Maintenant, je ne vois pas en quoi cela peut-être un problème. Si dans un dessin, tu fais pas exemple(setq ent (vlax-ename->vla-object (car (nentsel)))) (vla-delete ent)Puis un regen, l'objet sélectionné est bien effacé sur tous mes blocs. @+ Les Lisps de PatrickLe but n'est pas toujours placé pour être atteint, mais pour servir de point de mire.Joseph Joubert, 1754-1824
Matt666 Posté(e) le 24 décembre 2018 Auteur Posté(e) le 24 décembre 2018 Salut Patrick,Merci pour ta réponse. En fait je voudrais créer une routine qui cache toutes les entités hors bloc de celui édité. Comme une variable qui bascule l'état d'affichage des entités. Si pas d'édition de bloc, la routine ne fait rien, et si on est dans un bloc édité, la routine vérifie l'état d'une variable créée préalablement, si elle est à 1, toutes les entités hors bloc sont cachées, et inversement si 0. Du coup les entités du bloc édité posent problème puisqu'elles diffèrent de celles de la définition de bloc hors édition de bloc. Je sais pas si c'est très clair... En gros comment ne pas cacher les entités éditées puisqu'on ne peut les différencier des autres entités ? Merci à vous ! PS : et la vous allez me dire : ben ce que tu veux faire existe déjà, enfin... "Chacun compte pour un, et nul ne compte pour plus d'un."
Matt666 Posté(e) le 9 janvier 2019 Auteur Posté(e) le 9 janvier 2019 Salut, Je pense avoir trouvé comment retrouver les entités du bloc édité ; il suffit de garder la dernière entité créée dans le dessin (entlast) avant édition puis on passe sur une boucle avec (entnext) lors de l'édition du bloc. Si j'arrive à finir ce lisp, je le partagerai ici. Merci à vous. "Chacun compte pour un, et nul ne compte pour plus d'un."
Olivier Eckmann Posté(e) le 9 janvier 2019 Posté(e) le 9 janvier 2019 Bonjour, juste à faire attention si le dernier objet est un bloc avec attribut, ou une poly3D (pmaille...), le (entlast) te renvoie le dernier objet, mais (entnext) te renvoie les "sous-objets" suivants (VERTEX ou ATTRIB). Il faut bien aller jusqu'au SEQEND si nécessaire (drapeau 66 à 1 dans ton entlast) Olivier
Matt666 Posté(e) le 22 janvier 2019 Auteur Posté(e) le 22 janvier 2019 Ah, jamais compris le seqend.. Pour le moment je n'ai jamais eu l'utilité de cette condition, mais je vais creuser un peu. Ceci expliquerait peut-être un bug produit dans un lisp de normalisation d'entités à ma sauce. Merci Olivier. "Chacun compte pour un, et nul ne compte pour plus d'un."
bonuscad Posté(e) le 22 janvier 2019 Posté(e) le 22 janvier 2019 Oui, c'est exact. Je n'avais jamais remarqué et ce n'est pas logique.On sélectionne un bloc, puis modifbloc et on note l'ename d'un objet. On sort de l'éditeur. On sélectionne un autre bloc (mais le même nom que le précédent, juste une autre insertion), puis modifbloc, on regarde l'ename du même objet qu'auparavant, et ce n'est pas le même... Je ne suis pas sure de ce que je vais raconter....En fait je pense que quand on rentre dans l'éditeur de bloc, ce n'est pas avec les entités d'origine mais avec une copie de celles ci. et que quand on sort de l'éditeur en validant les modifications, il redéfini le bloc avec ces nouvelles entités dupliquées/modifiées.Un peu comme on faisait à l'ancienne (avant l'éditeur de bloc) mais là c'est plus transparent pour l'utilisateur.Donc je pense que c'est normal de ne pas retrouver le même ename. Choisissez un travail que vous aimez et vous n'aurez pas à travailler un seul jour de votre vie. - Confucius
Matt666 Posté(e) le 22 janvier 2019 Auteur Posté(e) le 22 janvier 2019 Salut bonuscad, C'est aussi mon avis. Une espèce d'image du bloc serait créée lorsqu'on l'édite. A voir si la commande bedit se comporte de la même façon (une nouvelle fonction sur Bricscad qui doit sûrement exister depuis des lustres sur Autocad). "Chacun compte pour un, et nul ne compte pour plus d'un."
Messages recommandés
Créer un compte ou se connecter pour commenter
Vous devez être membre afin de pouvoir déposer un commentaire
Créer un compte
Créez un compte sur notre communauté. C’est facile !
Créer un nouveau compteSe connecter
Vous avez déjà un compte ? Connectez-vous ici.
Connectez-vous maintenant