[AutoCAD LT 2024 - LISP]Créer, Modifier les CHAMPS en LISP

[reb_c1]

Bonjour à Toutes et à Tous,

Je cherche à créer, modifier les CHAMPS via une fonction LISP, mais visiblement il n'y a pas de table des CHAMPS ?

Comment aborder la création et la modification de ces CHAMPS, sans devoir passer par l'horrible commande _DWGPROPS ?

Je vous remercie.
Christian

[Luna3]

Coucou @reb_c1,

Alors malheureusement l'expression d'un champ dynamique n'a pas de documentation officielle à ce jour. Personnellement si jamais je désire créer un champ dynamique en via un LISP, je créé un champ factice manuellement correspondant au résultat escompté et j'étudie ensuite l'expression du champ pour comprendre sa structure et comment en créer un basé sur ces informations.
Par exemple si l'on prend un champ basé sur l'aire d'un objet existant:

%<\AcObjProp.16.2 Object(%<\_ObjId 2668039342416>%).Area \f "%lu2%pr1%ps[S= , m²]%ds44%ct8[12.5]%th32">%

Ensuite il faut découper la chaîne pour en comprendre sa structure:

%<\AcObjProp.16.2 Object(%<\_ObjId 

cette information semble (d'après mes tests) être une valeur constante à partir du moment que l'on utilise un champ Objet.

2668039342416

Correspond ici à l'ID de ton objet (vla-get-ObjectID) comme par exemple ta polyligne, etc... Ne pas oublier que si jamais tu crées un champ via un LISP tu devras utiliser la fonction (strcat) donc il te faudra évidemment convertir l'ID de ton objet en STR, soit (itoa (vla-get-ObjectID)).

>%).

Ceci est également constant car tu viens fermer la partie liée à l'ID de ton objet.

Area

Correspond au nom de ta propriété (ici Area pour l'Aire). Je ne sais toujours pas d'ailleurs s'il fait appel au nom Visual LISP de la propriété (vlax-dump-object) ou bien au nom des propriétés issues via (dumpallproperties)...bref

\f "%lu2%pr1%ps[S= , m²]%ds44%ct8[12.5]%th32">%

Ceci correspond au format et format supplémentaire que l'on souhaite ajouter à notre champ. Donc

%lu2

Correspond à un écriture décimale mais attention tout de même car certaines écritures d'un nombre font certes appel à %lu1 ou %lu5 mais certaines font appel à %lu2 et ajoute d'autres éléments, un peu comme pour les codes DXF pour les couleurs, si on défini la couleur d'un objet sur du RGB 172,45,36 alors on aura un code DXF 62 (= couleur ACI) ET un code DXF 420 (= TrueColor).

%pr1

correspond à la précision après la virgule, donc %pr1 signifie que l'on a 1 chiffre après la virgule par exemple.

%ps[S= , m²]

 Ici c'est si l'on rajoute un suffixe et/ou un préfixe (donc 'p' pour préfixe et 's' pour suffixe) et les deux sont séparés par une virgule. Donc si l'on ne veut qu'un suffixe on aurait

%ps[, m²]

et si on veut juste le préfixe on aurait

%ps[S= ,]

Ensuite le

%ds44

Cela correspond à ton séparateur décimal. Donc ici 44 correspond au code ascii de ton caractère, et 44 correspond à ",". Tandis que 32 correspond à " " par exemple. En lien avec le séparateur décimal, on a le séparateur des milliers donc ici c'est 32 donc " ". Evidemment %ds et %th ne peuvent pas avoir le même code ascii.

%th32

et le

%ct8[12.5]

correspond au coefficient que tu souhaites appliquer par exemple. Donc 12.5 correspond à la valeur que tu veux appliquer.

Evidemment si tu souhaites un champ sur une autre propriété ou même un champ non lié à un objet, etc... L'expression sera différente et il faudra étudier de nouveau ta chaîne pour comprendre comment la construire. Donc je ne t'ai donné qu'un simple exemple mais en réalité il y en a pleins et il faut les explorer selon les besoins.

PS: Si jamais vous trouvez une documentation technique détaillée sur l'expression d'un champ, je suis preneuse. J'avoue ne pas avoir cherché suffisamment pour regarder si une telle documentation existait.

Bisous,
Luna

[patrick.emin]

Bonjour @reb_c1 

Si une des réponses résout votre problème ou vous a permis de mieux le comprendre, voulez vous avoir l'amabilité de cliquer sur le bouton  APPROUVER LA SOLUTION  en bas de la réponse qui apporte une solution?
Cela facilitera la navigation de nos utilisateurs qui pourront directement atteindre la solution

Sachez qui si vous avez marqué une réponse comme solution par erreur, vous pouvez annuler ce marquage en cliquant sur le menu du fil (les trois points verticaux) et choisir "pas la solution"
Merci de ne pas accepter comme solution le message que vous êtes en train de lire.

[reb_c1]

AH que Coucou,Luna @Luna3 

Je te remercie pour tous ces détails. Mais il est vrai que ces CHAMPS sont une NEBULEUSE ! et c'est bien dommage. Comme les commandes _DWGPROPS et _FIELD ne sont pas MACROTABLES on est obligé d'inventer des BIDOUILLES.

Par contre je cherche, la aussi, un moyen MACROTABLE pour obtenir le _ObjId ?

Christian

[_gile]

---

@reb_c1 wrote:

Par contre je cherche, la aussi, un moyen MACROTABLE pour obtenir le _ObjId ?

---

À ma connaissance, ça n'est pas possible.

Les identifiants ObjectId sont basés sur des entiers codés sur 64 bits.

Ils ne sont donc pas accessibles en l'état via AutoLISP (où ils sont exposés sous la forme de ENAME) ce qui oblige à passer par Visual LISP (interface COM/ActiveX) et là encore, on ne peut les avoir que sous forme de chaîne de caractères avec (itoa (vla-get-ObjectId ...)) ou (vla-GetObjectIdString ...)*.

* vla-GetObjectIdString est obsolète.

[patrick.emin]

Bonjour @reb_c1 

Merci d’avoir participé à notre communauté ! Vos questions et leurs réponses aident tout le monde. Si des réponses vous paraissent appropriées, voulez vous avoir l'amabilité de cliquer sur le bouton  APPROUVER LA SOLUTION  en bas de la réponse qui apporte une solution?
Merci de ne pas accepter comme solution le message que vous êtes en train de lire.

[reb_c1]

Bonjour Patrick, @patrick.emin 

Visiblement, il n'y a pas de SOLUTION tant que ces commandes _FIELDS et _DWGPROPS ne respectent pas les STANDARDS des commandes en ligne de commande !

Comme les commandes :

   _INSERT = Case de dialogue-fenêtre / _-INSERT = commande standard en ligne de commande 

   _LAYER = Case de dialogue-fenêtre / _-LAYER = commande standard en ligne de commande 

   _STYLE = Case de dialogue-fenêtre / _-STYLE = commande standard en ligne de commande 

   etc.

et pour les 2 qui m'intéressent :

   _FIELDS = Case de dialogue / _-FIELDS = commande inconnue !!!!!

   _DWGPROPS = Case de dialogue / _-DWGPROPS = commande inconnue !!!!!

   et bien d'autres...

Christian

[DVaquand · Accepted solution]

Bonjour Christian

Il est vrai que la valeur décimale de "ObjId" n'est pas définie dans le code DXF d'un objet.
On ne récupère seulement que le code "Entité" de l'objet, exprimé en hexadécimal.
Ce code là est de type "Ename" et il n'y a pas de fonctions AutoLisp basiques qui permettent une conversion de cette valeur en valeur entière ou en chaine de caractères.
Comme le disent @Luna3  et @_gile  on peut récupérer ce code entité en Visual Lisp pour obtenir son "ObjId" en décimal.
Aussi, quelquefois il faut savoir penser différemment, comme par exemple "Comment construire 4 triangles équilatéraux avec 6 alumettes".
Bon revenons à notre AutoLisp basique (non Visual Lisp).
Donc si on souhaite convertir le code entité d'un objet "Entity Name", de type "Ename", en valeur décimale on peut simplement l'écrire dans un fichier texte. En relisant ce fichier texte on récupére ce code en tant que chaine de caractères.
A partir de là on peut supprimer, par la fontion "Substr", les caractères qui ne correspondent pas au code hexadécimal.
Ensuite, via un algorithme écrit par Lee Mac en 2011, on convertit cette valeur hexa en décimale pour obtenir enfin le fameux code "ObjId".
Il faut savoir qu'à chaque ouverture du même dessin, le code entité du même objet, change. Le code "Id" du champ se mettra à jour automatiquement. Ouf !

Voici un petit AutoLisp qui permet de récupérer ce code "Id".
Sauf à me tromper, je pense donc que maintenant ce code "ObjId" devrait être MACROTABLE pour toi !!!

(defun c:DV_ObjIdHexaVersDecimal ( / Obj_Ent Fichier Obj_Ent Ent_Hexa ValHexa ValDecimale)

(setq Obj_Ent (car (entsel)))

;; Mémorisation dans un fichier txt du code entité en tant que type "Ename"

;;; Chemin à redéfinir selon le poste

(setq Fichier (open "C:\\temp\\temp.txt" "w"))
(princ Obj_Ent Fichier)
(close Fichier)

;; Récupération du code entité en tant que chaine de caractères
;;; Chemin à redéfinir selon le poste
(setq Fichier (open "C:\\temp\\temp.txt" "r"))
(setq Ent_Hexa (read-line Fichier))
(close Fichier)

;; Suppression des caractères "<Nom d'entité: " au début et ">" à la fin du code entité
;; afin de ne conserver que les valeurs Hexadécimales

(setq ValHexa (substr Ent_Hexa 16))
(setq ValHexa (substr ValHexa 1 (- (strlen ValHexa) 1)))

;; Conversion de la valeur Hexa en Décimal

(setq ValDecimale (hex2dec ValHexa))

(print ValDecimale)

(princ)
)

;;; Code de Lee Mac 2011 ===========================================================================

(defun hex2dec ( str / l1 l2 mat pas vec x x1 )
(setq vec (mapcar '(lambda ( x ) (- x (if (< x 58) 48 55))) (vl-string->list (strcase str)))
pas (_pascalmatrix (length vec) '((1.0)))
mat pas
)
(repeat 5 (setq mat (mxm mat pas)))
(setq l1 (reverse (vxm vec mat))
x1 (car l1)
)
(while (< 0 x1)
(setq l2 (cons (chr (+ (fix (rem x1 10)) 48)) l2)
l1 (cdr l1)
x1 (+ (/ (fix x1) 10) (cond ((car l1)) (0)))
)
)
(apply 'strcat l2)
)

(defun _pascalmatrix ( n l )
(if (< n 2)
l
(_pascalmatrix (1- n)
(cons
(mapcar '+ (cons 0.0 (car l)) (append (car l) '(0.0)))
(mapcar (function (lambda ( x ) (cons 0.0 x))) l)
)
)
)
)

;; Matrix Transpose - Doug Wilson
;; Args: m - nxn matrix

(defun trp ( m )
(apply 'mapcar (cons 'list m))
)

;; Matrix x Matrix - Vladimir Nesterovsky
;; Args: m,n - nxn matrices

(defun mxm ( m n )
( (lambda ( a ) (mapcar '(lambda ( r ) (mxv a r)) m)) (trp n))
)

;; Matrix x Vector - Vladimir Nesterovsky
;; Args: m - nxn matrix, v - vector in R^n

(defun mxv ( m v )
(mapcar '(lambda ( r ) (apply '+ (mapcar '* r v))) m)
)

(defun vxm ( v m )
(mapcar '(lambda ( r ) (apply '+ (mapcar '* r v))) (trp m))
)

 Cordialement
Dominique VAQUAND
www.dovaq.fr

Si mon message propose une solution, veuillez cliquer sur "Accepter comme solution"
If my post offers a solution, please click "Accept as Solution"n o

[DVaquand]

Re bonjour Christian

Je n'avais pas vu que dans le code AutoLisp il y avait une fonction Visual Lisp.

Cela ne devrait pas fonctionner sur AutoCAD LT 2024.

Mais toi qui est un pro de Excel, tu peut faire une fonction qui convertit le code Hexa en Décimal et obtenir le "IdObj"

Cordialement
Dominique VAQUAND
www.dovaq.fr


Si mon message propose une solution, veuillez cliquer sur "Accepter comme solution"
If my post offers a solution, please click "Accept as Solution"

[_gile]

@DVaquand

AutoCAD LT 2024 supporte Visual LISP (excepté l'accès aux application externes vlax-GetObject, vlax-CreateObject, etc). Donc on peut très bien utiliser vla-get-ObjectId.

@reb_c1 

La demande initiale n'était pas comment utiliser les commandes _FIELDS et _DWGPROPS en ligne de commande, mais comment modifier un champ en LISP. question à laquelle @Luna3 a apporté une réponse détaillée.

[reb_c1]

Bonjour,

Merci à Tous pour vos réponses et je confirme que le LISP fonctionne avec une LT 2024... merci Dominique @DVaquand 

Du coup en associant le N° ID de l'objet et quelques CODES, on peut y arriver de façon COMME TOUJOURS !  détourné !

Quelques exemples de CODE :

surface d'un objet : %<\AcObjProp Object(%<\_ObjId ???>%).Area \f "%lu2">%
calque de l'objet  : %<\AcObjProp Object(%<\_ObjId ???>%).Layer>%
couleur de l'objet : %<\AcObjProp Object(%<\_ObjId ???>%).TrueColor>%
épaisseur de ligne : %<\AcObjProp Object(%<\_ObjId ???>%).Lineweight \f "%.2f mm%lw1">%
longueur de l'objet: %<\AcObjProp Object(%<\_ObjId ???>%).Length \f "%lu2%pr2">%
type ligne objet   : %<\AcObjProp Object(%<\_ObjId ???>%).Linetype>%
etc.

@_gile , j'ai depuis toujours su me passer du LISP avec les versions LT, mais j'étais limité avec les possibilités des commandes pour certaines NON MACROTABLES et je cite bien :   l'HORRIBLE commande _DWGPROPS et FIELDS bien sur... et je constate que finalement même en LISP c'est compliqué à gérer !

La QUESTION, aux développeurs, pourquoi ne pas avoir respecté le principe de développer une commande STANDARD en ligne de commande et après seulement développer l'interface via une FENETRE ?! mais Noël est passé on aura pas de réponse ! Je ne sais plus de quand date ces commandes ? version R14 peut-être ?

Christian

[_gile]

---

@reb_c1 wrote:

La QUESTION pourquoi ne pas avoir respecté le principe de développer une commande STANDARD en ligne de commande et après seulement développer l'interface via une FENETRE ?!

---

Ce n'est pas un "principe", en tout cas ça ne l'est plus quand les commandes deviennent complexes avec une grosse arborescence d'options imbriquées. Pour avoir développé quelques commandes de ce type, commencer par une boite de dialogue est bien plus simple et je n'aurais vraiment pas aimer avoir à faire qu'elles soient utilisables en ligne de commande.

[Luna3]

@reb_c1,

Je pense en effet que l'on s'est quelque peu éloigné du sujet de base. La question initiale était

---

@reb_c1  a écrit :

Bonjour à Toutes et à Tous,

Je cherche à créer, modifier les CHAMPS via une fonction LISP, mais visiblement il n'y a pas de table des CHAMPS ?

Comment aborder la création et la modification de ces CHAMPS, sans devoir passer par l'horrible commande _DWGPROPS ?

Je vous remercie.
Christian

---

donc autrement dit, comment créer et/ou modifier un champ dynamique en LISP. Il n'a jamais était question non seulement d'AutoCAD LT (2024, qui supporte de toute façon la majeure partie de la programmation Visual LISP) ni de l'absence des commandes _-FIELD et _-DWGPROPS.

Comme le dit @_gile ces commandes utilisent une boîte de dialogue en raison de l'absurde complexité de ces commandes en ligne de commande. Certaines commandes sont aussi bien utilisable via une boîte de dialogue qu'en ligne de commande mais si l'on regarde bien, ces commandes ne possède pas de complexité réelle et les boîtes de dialogue permettent juste de "simplifier" la saisie des informations pour un utilisateur/développeur. En effet si l'on regarde la commande _INSERT, on ne fait que renseigner le nom d'une définition de bloc (-> (getstring)) sans faute de frappes possible (via une liste déroulante), les coordonnées d'insertion X,Y,Z (-> (getpoint)), l'échelle selon les 3 axes (-> (getreal) x3), l'angle de rotation (-> (getangle) ou (getorient)) et c'est tout ! D'un point de vue programmation algorithmique, il n'y a aucune difficulté, aucune adaptation des questions en fonction des réponses, etc... Donc la traduction de cette boîte de dialogue en commande _-INSERT est vraiment simple. Je pense même que d'un point de vue programmation, la commande _-INSERT est arrivée en premier, puis l'utilisation d'une boîte de dialogue semblait plus agréable d'un point de vue utilisateur (car il y a un nombre limité de questions avant qu'un utilisateur s'agace et cherche un moyen plus..."rapide").

Maintenant si l'on s'intéresse aux commandes _DWGPROPS et _FIELD, on se rend facilement compte que la traduction de telles commandes sous forme d'une série de question devient un véritable casse-tête algorithmique en très peu de temps ! Car la commande _FIELD par exemple doit être en mesure de poser un nombre de question différent selon chaque réponse donnée, poser des questions différentes selon chaque réponse/question, corriger les erreurs de frappes, proposer des tonnes de possibilités, etc... cette commande _-FIELD serait bien plus qu'une usine à gaz et bien plus difficile à mettre en place je pense que sa version en boîte de dialogue.

Bref, pour en revenir à la question initiale : Il est possible de créer/modifier des champs dynamiques en LISP et même sur les versions LT (2024!) car les limitations LT n'impactent en rien les créations/modifications des champs dynamiques. Il est également possible de créer/modifier/supprimer des propriétés du dessin personnalisées via le LISP (je ne pense pas que le LT soit impacté à ce niveau là également). Et oui, c'est difficile à gérer même en LISP et c'est totalement normal ! Car le principe même des champs est complexe, donc forcément la programmation nécessaire qui en découle est elle-même complexe (après tout, il s'agit de lier deux entités entre-elles et de faire en sorte que si l'une change, l'autre change aussi et de pouvoir accéder aux propriétés principales de n'importe quel type d'objet avec une simple chaîne de caractères qui ne fait pas 300 pages ^^"). Donc au final, je comprends ton désarroi face à l'absence de commandes _-FIELD et _-DWGPROPS et du fait de ne pas pouvoir macroter la création d'un champ, mais il faut bien reconnaître la limite des macros, certes c'est très puissant mais cela ne permettra jamais de réaliser des tâches aussi complexe que la création de champs dynamiques et c'est bien pour cela qu'il existe le LISP, le VBA, etc... (c'est-à-dire des langages de programmation plus complexes). Et même au sein des langages de programmation complexes supportés par AutoCAD, il y a des différences. Certaines choses sont plus difficiles voire impossible à faire avec certains langages alors qu'avec d'autres, c'est plus simple ou faisable.

Bisous,
Luna

[reb_c1]

il me semble que le titre de mon sujet était pourtant clair ???   [AutoCAD LT 2024 - LISP]...

Christian

[reb_c1]

J'ai fait un saut de ligne, car effectivement cette remarque ne s'adressait pas à Toi GIlles... @_gile 

Je remercie pour ces compléments.

Christian

[CADaSchtroumpf]

En aparté!

Comme quoi les champs sont mal documenté...

En effet il est est possible avec le lisp d'obtenir des informations qui ne sont pas disponible dans les propositions faites dans la commande "CHAMP" ("_Field"), je sais qu'il y en a d'accessibles mais je ne pourrais les citer toutes.

Par exemple:

Obtenir le volume d'un SOLIDE3D (celui-ci n'est pas proposé dans la liste dans la commande champ!?!), or en lisp on peut l'obtenir grâce à ce code par exemple.

(vl-load-com)
(defun c:Label_Volume ( / js htx AcDoc Space n obj ename pt alpha nw_obj)
  (princ "\nSelect solid.")
  (while
    (null
      (setq js
        (ssget
          (list
            '(0 . "3DSOLID")
            (cons 67 (if (eq (getvar "CVPORT") 1) 1 0))
            (cons 410 (if (eq (getvar "CVPORT") 1) (getvar "CTAB") "Model"))
          )
        )
      )
    )
    (princ "\nAren't solid!")
  )
  (initget 6)
  (setq htx (getdist (getvar "VIEWCTR") (strcat "\nGive the height of the text <" (rtos (getvar "TEXTSIZE")) ">: ")))
  (if htx (setvar "TEXTSIZE" htx))
  (setq
    AcDoc (vla-get-ActiveDocument (vlax-get-acad-object))
    Space
    (if (= 1 (getvar "CVPORT"))
      (vla-get-PaperSpace AcDoc)
      (vla-get-ModelSpace AcDoc)
    )
  )
  (vla-startundomark AcDoc)
  (repeat (setq n (sslength js))
    (setq
      obj (ssname js (setq n (1- n)))
      ename (vlax-ename->vla-object obj)
    )
    (initget 1)
    (redraw obj 3)
    (setq
      pt (getpoint "\nPoint d'insertion")
      alpha 0.0
      nw_obj
      (vla-addMtext Space
        (vlax-3d-point pt)
        0.0
        (strcat
          "{\\fArial|b0|i0|c0|p34;"
          "%<\\AcObjProp.16.2 Object(%<\\_ObjId "
          (itoa (vla-get-ObjectID ename))
          ">%).Volume \\f \"%lu2%pr2%ps[V=,m³]\">%"
        )
      )
    )
    (redraw obj 4)
    (mapcar
      '(lambda (pr val)
        (vlax-put nw_obj pr val)
      )
      (list 'AttachmentPoint 'Height 'DrawingDirection 'InsertionPoint 'Layer 'Rotation)
      (list 5 (getvar "TEXTSIZE") 5 pt (getvar "CLAYER") alpha)
    )
  )
  (vla-endundomark AcDoc)
  (prin1)
)

[_gile]

---

@reb_c1 wrote:

il me semble que le titre de mon sujet était pourtant clair ???   [AutoCAD LT 2024 - LISP]...

Christian

---

Oui, très clair. Et par deux fois @Luna3 a répondu précisément à la question posée. C'est toi qui a fait dévier le sujet, notamment avec ta réponse #7 :

---

@reb_c1 wrote:

Bonjour Patrick, @patrick.emin 

Visiblement, il n'y a pas de SOLUTION tant que ces commandes _FIELDS et _DWGPROPS ne respectent pas les STANDARDS des commandes en ligne de commande !

---

[Luna3]

Coucou,
Yes parfaitement clair, mea culpa ^^"
Je ne devais pas être bien réveillée et je n'ai lu qu'une partie du titre, désolée

Bisous,
Luna

[reb_c1]

Salut Gilles @_gile 

C'est justement du fait du DEFAUT de ces 2 commandes que je me suis rabattu sur une solution en LISP et qui a motivé mon sujet !

Christian

[reb_c1]

Hello @Luna3 ,

No problemo, ça m'arrive aussi de lire parfois en DIAGONALE...  😁

Christian