Classement

Ah oui, bien vu, bis. Comme quoi, il n'est jamais inutile de lire l'aide d'une commande. Quant au or, à la place du if, c'est ce que j'expliquais un peu plus haut. Le if présenterai un intérêt s'il y avait un sinon. Dans le même esprit que or, on peut aussi utiliser cond. Amicalement Vincent

Ah oui, bien vu Merci Bruno @+

Oui et pour mémoire il me semble que cela peut également s'établir en natif, avec l'argument optionnel [default-data] de la fonction vlax-ldata-get: (vlax-ldata-get "DenisH" "EtiqPTRL_XY" "Oui") A+

Bonjour zebulon_ (or (setq EtiqXY (vlax-ldata-get "DenisH" "EtiqPTRL_XY")) (setq EtiqXY "Oui") ) Revient à faire (if (not (setq EtiqXY (vlax-ldata-get "DenisH" "EtiqPTRL_XY"))) (setq EtiqXY "Oui") ) @+

(= VARIABLE nil) peut aussi se dire (not VARIABLE) à quel moment on affecte la valeur "" à la ldata ? Si c'est un événement qui ne se produit jamais, cela ne sert à rien de le vérifier et le or semble inutile au début de DHConfEtiqPTRL Tantôt, tu affectes la valeur "O", tantôt la valeur "OUI". Il faudrait choisir, je dirais plutôt "OUI". Pour moi, l'algorithme serait : 1 je mets dans une variable le contenu du dictionnaire. Si c'est nil, j'initialise la variable avec la valeur par défaut, disons "Oui" 2 je pose la question "Oui" "Non" que je stocke dans la même variable 3 je mets le contenu de la variable dans le dictionnaire Donc, un vlax-ldata-get au début et un vlax-ldata-put à la fin. Entre les 2, c'est dans une variable. (defun c:DHConfEtiqPTRL (/ EtiqXY EtiqZ) (if (not (setq EtiqXY (vlax-ldata-get "DenisH" "EtiqPTRL_XY"))) (setq EtiqXY "Oui") ) (if (not (setq EtiqZ (vlax-ldata-get "DenisH" "EtiqPTRL_Z"))) (setq EtiqZ "Oui") ) (initget "Oui Non") (setq EtiqXY (cond ((getkword (strcat "\nÉcrire l'X et l'Y [Oui/Non] ? <" EtiqXY ">"))) (EtiqXY) ) ) (initget "Oui Non") (setq EtiqZ (cond ((getkword (strcat "\nÉcrire le Z [Oui/Non] ? <" EtiqZ ">"))) (EtiqZ) ) ) (princ (strcat "\n\nConfiguration actuelle : Étiquette XY = " EtiqXY " Étiquette Z = " EtiqZ ) ;_ Fin de strcat ) ;_ Fin de princ (vlax-ldata-put "DenisH" "EtiqPTRL_XY" EtiqXY) (vlax-ldata-put "DenisH" "EtiqPTRL_Z" EtiqZ) (princ) ) pour réutiliser les valeurs par défaut dans getkword, j'ai enlevé le strcat. Donc, je stocke "Oui" ou "Non". Mais dans l'autre programme on peut tout aussi bien écrire (= VARIABLE "Oui") Amicalement Vincent

Bonjour, La deuxième invite est la valeur de retour de ta fonction lisp, le préfixe c: permet d'appeler ta fonction lisp sur la ligne de commande comme une commande AutoCAD, mais cela reste une expression Lisp qui retourne toujours la dernière expression évalué. Pour évité cette "impression" d'écho sur ta ligne de commande en sortie de programme insère un (princ) qui te renverra un blanc. A+

il faut regarder l'aide de initget, notamment le tableau qui donne la signification des valeurs de bits. Si tu écris (initget 1 "Oui Non"), le bit 1, signifie "Interdit l'entrée nulle". Si tu veux accepter l'entrée nulle, il faut écrire (initget "Oui Non"). Le getkword qui suivra pourra donc renvoyer soit "Oui", "Non" ou nil (defun c:initsel ( / Txt_Alti) (if (not (setq EtiqXY (vlax-ldata-get "DenisH" "EtiqPTRL_XY"))) (setq EtiqXY "Oui") ) (while (/= (type Txt_Alti) 'LIST) (initget "Configurer") (if (not (setq Txt_Alti (entsel "\nSélectionner l'altitude ou [Configurer] <Configurer>"))) (setq Txt_Alti "Configurer") ) (if (= Txt_Alti "Configurer") (progn (initget "Oui Non") (setq EtiqXY (cond ((getkword (strcat "\nÉcrire l'X et l'Y [Oui/Non] ? <" EtiqXY ">"))) (EtiqXY) ) ) ) ) ) (vlax-ldata-put "DenisH" "EtiqPTRL_XY" EtiqXY) (setq Txt_Alti (car Txt_Alti)) ) entsel n'est pas polyvalent à ce point ! Cette fonction permet de sélectionner une entité ou de taper des textes qu'on trouve dans la partie [chaine] de initget. On imagine bien qu'on ne peut pas prévoir toutes les altitudes dans cette chaine de caractères. Il me semble que la solution serait de rajouter une option dans initget : (initget "Saisie Configurer"), puis de faire un cond pour tester si l'utilisateur a tapé "Saisie" ou "Configurer". Dans le cas "Configurer", on fait ce qu'il y a ci-dessus, dans le cas "Saisie", on fait un getdist. A noter que getdist est sensible aux bits d'initget : 1 pas de nul, 2 pas de zéro, 4 pas de négatif. Un (initget 7) me semblerait pas mal, sauf si on peut avoir des données négatives ou nulles. Dans ce cas (initget 1). (vlax-ldata-list dict) renvoie les valeurs stockées dans un dictionnaire. Amicalement Vincent

Bonjour, (/= (cdr (assoc 0 (entget (car Txt_Alti)))) "LINE") a été pris comme exemple. Cela ne doit pas s'adapter à ton cas (bloc ou attribut ou texte ?) après ces lignes (if (not (setq Txt_Alti (entsel "\nSélectionner l'altitude ou [Configurer] <Configurer>"))) (setq Txt_Alti "Configurer") ) Txt_Alti ne peut contenir que "Configurer" ou une liste renvoyée par entsel (Si Txt_Alti n'est pas une entité sélectionnée peut donc se dire (if (= Txt_Alti "Configurer") (progn ... ) ) Ainsi, (Si Txt_Alti = "Configuration" dans le alors devient inutile, puisqu'on en est déjà sûr ! Et il suffit de tester successivement EtiqXY et EtiqZ, avec des if puisque tu veux tester l'un ET l'autre ; cond n'est donc pas plus simple dans ce cas. Je me demandais aussi à quel endroit tu veux faire le vlax-ldata-put et je me demandais aussi si les vlax-ldata-get du début ne te renvoient pas un nil lors du premier lancement de ce lisp dans un nouveau fichier alors que, plus loin, tu compares avec <> "". Nil et "", c'est pas pareil ! Pour terminer (Si non (setq Txt_Alti (car Txt_Alti)) n'est pas placé judicieusement. Il faut attendre d'être sorti de la boucle while, dont on ne sort que lorsqu'on a sélectionné une entité (la bonne de préférence). Donc, à la sortie du while, on peut se contenter de (setq Txt_Alti (car Txt_Alti)) Amicalement Vincent

arrivé là, pose-toi la question de ce qu'il y a dans Txt_Alti. Si ce n'est pas un texte, forcément, ça va planter la fonction strcat. Ensuite, plus loin, je n'ai pas trop essayé de comprendre, mais il y a une chose qui est certaine : quand on a une série de if, il est souvent plus simple et plus lisible d'utiliser (cond (test1 resultat1 ...) ...) En gros, c'est plus simple de faire une étude de cas plutôt qu'une série de if imbriqués et des progn à la pelle. Au niveau de la boucle while, on peut aussi rajouter une condition supplémentaire pour vérifier si l'utilisateur a cliqué sur le bon élément. Je pense qu'avec un or, ça devrait fonctionner. Par exemple, si je ne veux accepter que les lignes (defun c:initsel ( / Txt_Alti) (while (or (/= (type Txt_Alti) 'LIST) (/= (cdr (assoc 0 (entget (car Txt_Alti)))) "LINE")) (initget "Configurer") (if (not (setq Txt_Alti (entsel "\nSélectionner l'altitude ou [Configurer] <Configurer>"))) (setq Txt_Alti "Configurer") ) (if (= Txt_Alti "Configurer") (progn (alert "configurer ici") ) ) ) (setq Txt_Alti (car Txt_Alti)) ) or évalue les expressions de gauche à droite, en cherchant une expression non-nil. Si une telle expression est trouvée, or ne fait plus d'autres évaluations et retourne T. Si toutes les expressions sont nil, or retourne nil. Au départ, Txt_alti contient nil ; (/= (type nil) 'LIST) retourne T ; or s'arrête là et retourne T. Puis, mettons qu'on tape "C" au clavier ; (/= (type "Configurer") 'LIST) retourne T ; or s'arrête là et retourne T. Puis, mettons qu'on sélectionne un objet ; (/= (type '(<Nom d'entité: 7ffffb05e00> (2401.32 1472.43 0.0))) 'LIST) retourne nil ; on passe au deuxième élément du or qui ne retournera un deuxième nil que s'il s'agit d'une ligne. L'intérêt du or est justement qu'il ne fait plus d'autres évaluations dès qu'une expression non-nil est trouvée, ce qui nous permet d'utiliser dans la seconde partie du or des fonctions entget, assoc, cdr, car... qui ne fonctionnent bien que lorsqu'elles agissent sur une liste. On imagine bien que, si la deuxième partie du or était évaluée lorsque Txt_Alti contient "Configurer", cela provoquerait un plantage immédiat. La fonction and présente le même intérêt, puisqu'elle stoppe toute évaluation et retourne nil, si l'une des expression resulte en nil ; la fonction and retourne T uniquement lorsque toutes les expressions retournent T. par exemple : (and nil (car "A")) renvoie nil et ne plante pas le lisp (and T (car "A")) renvoie ; erreur: type d'argument incorrect: consp "A" ; et plante le lisp Dans le lisp plus haut, on a utilisé une boucle Tant que Condition ... ... Répéter qui fonctionne 0 fois ou n fois ; et là c'est le ou logique qui s'impose. Dans d'autre langages, il y a une boucle avec la condition d'arrêt à la fin (repeat until du Pascal par exemple, mais qui n'existe pas en lisp) Répéter ... ... Jusque Condition qui fonctionne 1 fois ou n fois ; et là, je pense qu'on aurait plutôt utilisé le et logique Bonne bidouille ! Amicalement Vincent

Bonjour, la fonction (initget [bits] [chaine]) permet d'établir différentes options qui seront utilisées par la prochaine fonction getxxx, entsel, nentsel (sauf getstring, getenv et getvar). La fonction entsel que tu utilises fait donc partie de la liste des fonctions "sensibles" à initget. entsel ne gère que les mots clés entrés dans [chaine] car cette fonction ne prend en compte aucun bit de contrôle. (initget 128) est donc inutile avec entsel. (defun c:initsel ( / Txt_Alti) (while (/= (type Txt_Alti) 'LIST) (initget "Configurer") (if (not (setq Txt_Alti (entsel "\nSélectionner l'altitude ou [Configurer] <Configurer>"))) (setq Txt_Alti "Configurer") ) (if (= Txt_Alti "Configurer") (progn (alert "configurer ici") ) ) ) (setq Txt_Alti (car Txt_Alti)) ) Quant aux questions qui appellent des réponses oui/non, je te propose de regarder l'aide de getkword, qui fait partie des fonctions getxxx dont je parle ci-dessus et qu'on peut utiliser également avec initget Amicalement Vincent