Synthèse de la discussion CADxp : Récupérer une partie d’un nom de calque

Développement Programmation Macros Scripts
, ,
1

Synthèse de la discussion CADxp : Récupérer une partie d’un nom de calque

Introduction : Contexte et Enjeux Techniques

Cette analyse technique décortique une discussion du forum CADxp pour en extraire un cas d’étude exemplaire sur le dépassement des limites natives d’AutoCAD®. La discussion, initiée le 5 septembre 2018, porte sur une problématique précise : la recherche d’une méthode pour extraire et afficher dynamiquement une partie spécifique du nom du calque d’un objet dans un dessin.

Au fil des échanges, les participants ont exploré plusieurs pistes, mettant en lumière les capacités et les limites des outils standards du logiciel. Les thèmes abordés incluent les limitations des Champs (Fields), la fonctionnalité des objets RTEXT, la syntaxe des expressions DIESEL, et finalement, le recours à la programmation LISP comme solution avancée pour surmonter les obstacles rencontrés. Cette synthèse retrace le déroulé chronologique de cette résolution collaborative, illustrant une approche pertinente pour tout utilisateur cherchant à automatiser des tâches de documentation dans AutoCAD®.

1. Déroulé Chronologique de la Discussion

1.1. L’Exposition du Problème Initial

Une résolution efficace commence toujours par une définition claire du besoin. L’utilisateur Tryks a initié la discussion en exposant un défi technique précis, qu’il avait déjà commencé à explorer. Sa demande peut se décomposer comme suit :

  • Objectif : Extraire une sous-chaîne de caractères à partir du nom d’un calque. Par exemple, pour un calque nommé « lot n°1 », l’objectif est de n’afficher que le caractère « 1 ».
  • Première tentative : L’utilisation d’une expression DIESEL, $(substr, $(getvar, clayer), 8,3) (les valeurs 8 et 3 dépendant bien entendu de la structure exacte du nom de calque), s’est avérée fonctionnelle pour extraire une partie du nom du calque.
  • Le blocage : Cette méthode présente une contrainte majeure, car elle ne s’applique qu’au calque courant (variable système clayer). Elle ne permet pas de cibler le calque de l’objet auquel le texte (ou le champ) est associé.

Le cœur du problème était donc de trouver un moyen de lier dynamiquement l’extraction de l’information au calque de l’objet cible, plutôt qu’à une variable globale du dessin.

1.2. L’Exploration des Solutions Natives et leurs Limites

La démarche logique dans un environnement logiciel complexe comme AutoCAD® est d’abord d’explorer les outils standards. Les premiers échanges ont rapidement confirmé les limites de ces fonctionnalités pour répondre au besoin de Tryks.

L’utilisateur Patrick_35 a d’abord confirmé que la commande RTEXT ne pouvait pas, de manière native, récupérer le nom du calque de l’objet lui-même pour le traiter. L’attention s’est alors portée sur les Champs, plus puissants pour extraire des propriétés d’objets. Une tentative a été faite pour combiner la flexibilité des Champs avec la capacité de manipulation de texte des expressions DIESEL. Cependant, cette approche a mené à une impasse technique fondamentale :

  1. La manipulation : La méthode consistait à créer un Champ pointant vers la propriété « Calque » d’un objet, à copier sa formule interne, puis à la coller dans une expression DIESEL de type $(substr, ... ).
  2. Le faux espoir : Graphiquement, le résultat semblait correct lors de la création initiale du champ.
  3. L’échec technique : Le mécanisme s’est révélé non dynamique en raison de l’ordre d’évaluation du moteur d’AutoCAD®. Lors d’une mise à jour (REGEN ou manuelle), le moteur résout d’abord le champ interne (AcObjProp) en le convertissant en une chaîne de texte statique (le nom du calque, par exemple « lot n°1 »). C’est seulement après cette conversion que l’expression DIESEL externe $(substr, ...) est évaluée. À ce stade, le lien dynamique avec l’objet est déjà rompu, et la formule elle-même est réécrite avec le nom statique du calque. Patrick_35 a donc logiquement conclu que cette méthode n’avait « aucun intérêt ».

Il est ainsi devenu clair que les outils intégrés, qu’il s’agisse de RTEXT, des Champs standards ou des expressions DIESEL utilisées isolément, se révélaient insuffisants pour répondre à cette demande de manière dynamique et fiable.

1.3. Le Point de Bascule : L’Intervention du LISP

Lorsque les fonctionnalités natives d’un logiciel atteignent leurs limites, la personnalisation par la programmation devient la voie privilégiée pour développer des solutions sur mesure. L’intervention de l’utilisateur bonuscad a marqué le tournant de la discussion.

Son raisonnement, résumé par la remarque « C’est marrant on peut le faire en lisp, mais manuellement j’y arrive pas », l’a conduit au constat qu’il est « impossible d’insérer un champ dans l’expression diesel » de manière à conserver le lien dynamique via l’interface standard. Il a donc proposé une approche radicalement différente : une routine LISP.

Ce code agit comme un « constructeur de champ ». Sa fonction principale est de générer programmatiquement une chaîne de caractères MText contenant une formule parfaitement syntaxée pour le moteur de champs d’AutoCAD®. La routine imbrique un champ ciblant l’identifiant unique d’un objet (_ObjId) à l’intérieur d’une expression DIESEL, une opération irréalisable manuellement. C’est cette construction qui a permis de cibler dynamiquement l’objet, de récupérer le nom de son calque et d’en extraire la partie souhaitée.

Tryks a testé cette première version et a confirmé qu’elle fonctionnait, tout en notant deux limitations : l’impossibilité de choisir l’emplacement du champ et le fait que le champ nécessitait une mise à jour manuelle. Ce comportement s’explique par le fait que, bien que dynamique, le champ ne s’actualise pas toujours avec un simple REGEN, selon la configuration de la variable système FIELDEVAL.

1.4. La Finalisation de la Solution

Le processus de développement d’outils personnalisés est souvent itératif, s’affinant grâce aux retours des utilisateurs. En réponse aux remarques de Tryks, bonuscad a rapidement proposé une seconde version améliorée de sa routine LISP, nommée defun c:tryks.

Cette nouvelle version intégrait les améliorations suivantes :

  • La possibilité pour l’utilisateur de spécifier un point d’insertion pour le champ de texte.
  • La possibilité de définir la hauteur du texte.

Avec ces ajustements, la routine devenait un outil pratique et pleinement fonctionnel. Tryks a validé cette version finale en confirmant qu’elle « marche nickel », apportant une solution complète et élégante à son problème initial.

2. Synthèse des Points Clés de la Résolution

Cette discussion illustre plusieurs principes fondamentaux pour les utilisateurs avancés d’AutoCAD® qui cherchent à optimiser leurs flux de travail. Les points essentiels qui ont mené à la résolution sont les suivants :

  • Inefficacité des méthodes standards : Ni RTEXT, ni les Champs, ni les expressions DIESEL utilisés de manière conventionnelle ne pouvaient résoudre le problème. Leur limitation réside dans l’incapacité à appliquer une fonction de manipulation de chaîne de caractères (comme substr) sur une propriété (le nom du calque) qui est elle-même récupérée dynamiquement depuis un objet spécifique.
  • Le rôle crucial du LISP : Le passage à l’automatisation via une routine LISP a été indispensable. Le LISP n’a pas seulement exécuté une commande ; il a agi comme un constructeur pour bâtir une syntaxe de champ complexe que l’interface utilisateur d’AutoCAD® ne permet pas de créer manuellement.
  • La puissance de la formule combinée : La solution finale repose sur une imbrication intelligente : une expression DIESEL $(substr, ...) qui encapsule un champ AcObjProp. Ce champ cible un objet via son identifiant unique (_ObjId), créant ainsi un lien persistant et unique avec une entité spécifique de la base de données du dessin. C’est cette combinaison qui assure à la fois le ciblage dynamique et la manipulation du texte.
  • L’importance de la collaboration : La résolution n’aurait pas été possible sans l’échange constructif entre les membres du forum. La définition claire du problème par Tryks, les analyses des limites par Patrick_35 et l’expertise en programmation de bonuscad ont convergé pour produire une solution robuste et partagée avec la communauté CADxp.

Conclusion

Le défi posé, bien que spécifique, illustre un cas d’usage classique où les fonctionnalités standards d’AutoCAD® peuvent être transcendées grâce à la personnalisation. La discussion démontre que pour des besoins d’automatisation avancés, la maîtrise d’outils comme le LISP est essentielle pour construire des solutions dynamiques et véritablement adaptées aux flux de travail des utilisateurs.

Pour une analyse détaillée des échanges et pour accéder aux codes LISP partagés par les membres, il est recommandé de consulter la discussion originale sur le forum CADxp.