zebulon_

Il faut que j'interprète cette affirmation de façon ironique, je suppose. Sinon, j'ai une grande nouvelle à annoncer à la France : le département des Vosges a été colonisé par les chinois. Et cela remonte à la fin des années 1960, début des années 1970. Plus sérieusement, cet ouvrage a été réalisé en 1970 à Bussang (département 88, RN66 Bar-le-Duc à Bâle) par feue la CITRA (Compagnie Industrielle de Travaux pour la France) sise à Paris 8ème au 16, bd Malesherbes. Juste pour mettre les chinois hors de cause, sur ce coup là. On ne les a pas attendu ! Amicalement Vincent

Bonjour, oui c'est vrai j'ai oublié, lorsqu'on modifie le sommet d'une polyligne 3D (ou une ancienne polyligne) ou un attribut, il faut mettre à jour l'entité complexe à l'écran avec entupd. C'est ce que dit l'aide de la fonction entupd. Cependant, lorsque j'essaye sans cette fonction, l'affichage se regénère aussi. En tout cas chez moi. Amicalement Vincent

Bonjour, pardon d'avoir mal interprété. Mais je ne pense pas qu'on faisait plus attention avant qu'aujourd'hui, compte tenu du nombre d'énormités que je peux observer sur les ouvrages que je suis amené à réparer. Et les énormités en question ne sont pas dues à des erreurs de plan. La photo jointe, qui peut faire sourire, donne une idée de la manière dont on faisait attention sur les chantiers. Sur le même ouvrage, on n'avait pas non plus les épaisseurs de béton indiquées sur le plan : le béton avait coulé un peu plus à droite qu'à gauche dans les radiers de voussoirs... Les câbles de précontrainte n'étaient pas non plus au endroits indiqués sur les plans et il manquait 15cm à la portée centrale, toujours par rapport aux cotes données sur les plans. Et cet ouvrage n'est pas un cas isolé. Donc, dire que les mecs sur le chantier faisaient plus attention hier qu'aujourd'hui me parait au moins exagéré. Hier comme aujourd'hui, ils interprètent (eux aussi) un plan et ils se plantent. Parfois plus, parfois moins. Amicalement Vincent

Bonjour, Je ne m'étais jamais posé la question. ATTSYNC ne change pas les valeurs affectées aux attributs dans les blocs existants. Quant à BATTMAN Synchroniser, cela met à jour toutes les occurrences du bloc sélectionné avec les propriétés d'attribut actuellement définies, mais cette opération n'a aucune incidence sur les valeurs affectées aux attributs de chaque bloc. Donc je sèche et je ne sais pas autrement qu'en programmation (defun c:reatt (/ ATT EN B ATT_TAG B_NAME e DEF) (setq ATT (car (nentsel "\nAttribut à initialiser : "))) (if (= (cdr (assoc 0 (entget ATT ))) "ATTRIB") (progn (setq EN (entget ATT)) (setq B (cdr (assoc 330 EN))) (setq ATT_TAG (cdr (assoc 2 EN))) (setq B_NAME (cdr (assoc 2 (entget B)))) (setq e (tblobjname "BLOCK" B_NAME)) (while (and (not DEF) (setq e (entnext e))) (and (= (cdr (assoc 0 (entget e))) "ATTDEF") (= (cdr (assoc 2 (entget e))) ATT_TAG) (setq DEF (cdr (assoc 1 (entget e)))) ) ) ;; mettre à jour l'attribut (setq EN (subst (cons 1 DEF) (assoc 1 EN) EN ) ) (entmod EN) (entupd ATT) ) ) (princ) ) Maintenant, il y a peut être une commande ou un express tool qui permet de faire la même chose Amicalement Vincent

Bonjour, une visionneuse me parait également être la solution. Cependant, le problème de responsabilité soulevé par Didier n'est pas à balayer d'un revers de main, même si celui qui a fait le plan et celui qui réalise la pièce sont de la même société. Par contre, je ne suis pas tout à fait d'accord avec rappel : comment faisait-on avant la DAO*** ? on faisait attention. compte tenu que je fais beaucoup de réparations d'ouvrages d'art et que cela m'amène à consulter et à redessiner avec Autocad des plans qu'on faisait avant. Et les plans faits à la main, ce n'est pas toujours génial non plus. J'en arrive à la conclusion que ce n'est pas seulement l'outil qui fait la qualité du travail, mais avant tout le savoir faire de l'ouvrier et aussi le temps qu'on lui laisse pour faire ce travail. Amicalement Vincent

C'est mieux de préciser, Mais, même avec un chantier à l'intérieur, c'est moins simple pour bosser dans de bonnes conditions :D ta première mouture n'avait aucune chance de fonctionner. Je rejoins ce que disait Didier : allez! au boulot!. Tu as quelque chose qui semble fonctionner comme tu aurais voulu que ça fonctionne. Maintenant, essaye de comprendre comment. C'est toujours à partir d'exemples qu'on décortique pas à pas qu'on découvre le mieux, j'en suis convaincu. Ce n'est pas de l'empirisme, c'est de l'apprentissage... mais ça prend du temps. Apprendre à marcher, ça prend du temps aussi, mais c'est mieux que de passer sa vie à ramper, non ? moi, c'est un moins vieux manuel de la version 12 (pas 2012, 12 !) édité en septembre 1992. Put.. ça fait 23 ans que je le potasse, ce bouquin ! Amicalement Vincent

Bonjour, une piste pour étayer ta recherche (vl-load-com) (defun extract_attrib (E ETIQ / LATT ATT REP) (if (= (type E) 'ENAME) (setq E (vlax-ename->vla-object E)) ) (setq LATT (vlax-invoke E 'getAttributes)) (foreach ATT LATT (if (= (vla-get-TagString ATT) ETIQ) (setq REP (vla-get-TextString ATT)) ) ) REP ) (defun c:3p () (setq M1 (getstring "\nPoint 1 ? ")) ; saisie du matricule du point (setq M2 (getstring "\nPoint 2 ? ")) ; saisie du matricule du point (setq M3 (getstring "\nPoint 3 ? ")) ; saisie du matricule du point (setq LMAT (list M1 M2 M3)) ;; jeu de sélection qui contient tous les blocs dont le nom est "TCPOINT" (setq js (ssget "_X" '((0 . "INSERT") (2 . "TCPOINT")))) (setq LREP nil) (setq I 0) (while (and (< I (sslength js)) (< (length LREP) 3)) (setq e (ssname js I)) (setq I (+ I 1)) ;; si l'attribut "MAT" est l'un des 3 saisis on met dans la liste LREP le point d'insertion du bloc (if (member (extract_attrib e "MAT") LMAT) (setq LREP (cons (cdr (assoc 10 (entget e))) LREP)) ) ) (if (< (length LREP) 3) (alert "pas assez de points") (progn (command "_ucs" "_3P" "_non" (trans (nth 0 LREP) 0 1) "_non" (trans (nth 1 LREP) 0 1) "_non" (trans (nth 2 LREP) 0 1)) (command "_circle" "_3P" "_non" (trans (nth 0 LREP) 0 1) "_non" (trans (nth 1 LREP) 0 1) "_non" (trans (nth 2 LREP) 0 1)) (command "_ucs" "_p") ) ) ) je n'ai pas Covadis et j'ai supposé que les points topo sont des blocs qui s'appellent "TCPOINT" avec un attribut qui s'appelle "MAT" et qui représente le matricule. Si ce n'est pas ça, tu pourras changer facilement dans le lisp. Je t'invite à bien assimiler dans un premier temps la fonction ssget (et toutes ses petites copines ssname, sslength...) et regarder ce qu'en dit l'aide. Elle est vraiment très importante. Ensuite, il est plus malin de mettre les commandes en anglais dans les (command...), pour des raisons de traduction qui peuvent varier entre les différentes versions d'autocad et aussi pour permettre au lisp de fonctionner même sur un autocad non français. Ensuite, quand on commence à jouer avec les scu, il faut faire attention à ce que le lisp nous renvoie : c'est toujours des points en scu général. Donc, il ne faut pas oublier de transformer ces points pour les avoir en scu local lorsqu'on utilise une ligne (command...). D'où l'utilité de la fonction trans. Il faut aussi veiller à la variable "UCSFOLLOW". Si elle est active la modification du SCU génère une vue en plan du nouveau SCU dans la fenêtre courante. Donc, c'est mieux qu'elle soit inactive si on ne veut pas se taper des regénérations intempestives. Enfin, il faut aussi faire attention aux accrochages aux objets quand on utilise (command ...) et qu'on lui injecte un ou des points. Si l'accrochage aux objets est actif, on peut s'accorcher à une extrémité, un centre... qui peuvent être parfois très éloignés du point qu'on désire avoir (ou pas... mais le problème reste le même, ce n'est pas le bon point !). D'où l'importance du "_non" avant d'injecter un point pour éviter un accrochage "parasite" Amicalement Vincent

Je confirme : ;\farial;\I1 ça marche aussi et c'est sans doute plus simple. Le I doit être majuscule et il ne faut pas oublier le ; après arial. Amicalement Vincent

Merci Patrick pour le complément. On y voit qu'il reste quand même des zones d'ombre dans le grimoire, aux endroits qui sont marqué avec des ??? Olivier, tu indiques \i1. Je n'ai pas essayé, mais ça ne serait pas plutôt |i1 ? Quant au |c0|p34, comme dit ci-dessus, je ne sais pas ce que cela veut dire. J'ai simplement pompé à partir de l'index. En tout cas, |b0 ça veut dire que ce n'est pas en gras, mais |c0 ce n'est pas la couleur comme tu sembles le penser. La couleur c'est ;\Cn; où n est l'index de la couleur. Complément après recherche Codes in mtext format string are mining: \fArial Black - True type font typeface \Ftxt.shx - shx font name,used without codes |b, |i, |c, |p |b1 / |b0- bold on/off |i1 / |i1- italic on/off |c## - character set |p## - pitch and family donc, le |c0 ça voudrait plutôt dire qu'on utilise un jeu de caractères occidental (pas du chinois, du grec etc...) Amicalement Vincent

Bonjour, \I1, c'est presque ça mais pas complètement. Le truc pour trouver est de créer un texte avec la commande mtext, puis de changer le style du texte en italique, puis d'observer ce que cela donne quand on affiche les propriétés du texte, au niveau de l'index. Puis de "pomper" les signes cabalistiques qu'on y trouve. Dans notre cas ;\farial|b0|i1|c0|p34; Amicalement Vincent

Bonsoir, il est possible de les enlever, voire de les remplacer par d'autres caractères. Voir ici C'est en anglais, mais c'est bien illustré. Amicalement Vincent

Bonjour, pourquoi ne pas utiliser les unités alternatives ? avec un facteur à 0.25 et un positionnement en dessous. C'est disponible dans le style de cote entre "unités principales" et "tolérances" Amicalement Vincent ah, je vois qu'on est deux à donner la même piste qui donne un résultat dynamique, en prime.

Bonjour, effectivement avec la commande MODIFATTRINSITU, on arrive sans le lisp Je ne connaissais pas cette commande. Merci pour le retour d'expérience. Amicalement Vincent

Bonjour, si on a des attributs à lignes multiples, on dispose d'un éditeur un peu plus évolué et de la possibilité de transformer un attribut de minuscule en majuscule ou inversement. Pour des attributs simples, cela ne semble pas être le cas. Sinon, il y a cette possibilité : (vl-load-com) (defun attstrcase (flag / e obj tx) (setq e (car (nentsel "\nSélectionner un attribut : "))) (cond ((null e) (alert "Rien sélectionné !") ) ((= (cdr (assoc 0 (entget e))) "ATTRIB") (setq obj (vlax-ename->vla-object e)) (setq tx (vla-get-textstring Obj)) (vla-put-textstring obj (strcase tx flag)) ) (T (alert "Pas un attribut !") ) ) ) (defun c:attU () (attstrcase nil) (princ) ) (defun c:attL () (attstrcase T) (princ) ) (prompt "\nattU pour mettre un attribut en majuscules") (prompt "\nattL pour mettre un attribut en minuscules") (princ) mais cela gère l'ensemble du texte de l'attribut, alors qu'avec un éditeur on peut sélectionner une partie du texte. Amicalement Vincent

Bonjour, ATTACHERMATERIAU Amicalement Vincent

Lorsque la connaissance et l'ignorance sont inversement proportionnels à la position hiérarchique : tout le problème est là ! C'est pour ça que, personnellement, je préfère une relation maître/élève que chef/subordonné. Le maître accepte d'être dépassé par son élève, ce sera même un honneur pour lui. Ce n'est évidemment pas le cas d'un chef qui admettra difficilement qu'on veuille devenir calife à sa place. Amicalement Vincent

Tous les règlements commencent comme ça. Il n'y a qu'à regarder les 10 commandements. Premier commandement : Un seul Dieu tu aimeras et adoreras parfaitement. :) Amen ! Amicalement Vincent

Moi pareil... Amicalement Vincent

Le chef foire aussi ! Mais bon, comme le chef a toujours raison, même (et surtout !) quand il a tort. Et je ne dis pas ça parce que je n'aime pas les chefs. Mais utiliser un caractère qui permet de filtrer la liste des noms de calque dans le nom d'un calque lui-même me parait être une hérésie. # fait partie de ce que les anglais appellent un "wildcard character", qu'on peut traduire par caractère joker, au même titre que @, ~, [, ], *, ? ... (voir la fonction lisp wcmatch) et qui peut être utilisé pour filtrer les calques. Si le nom du calque contient déjà un caractère joker, un éventuel filtrage risque fort de devenir foireux également. J'en veux pour preuve ici ce qui est arrivé à un filtrage à cause d'un caractère [. Qu'elle idée aussi d'autoriser # dans les noms de calques ! Si Autodesk avait eu la lucidité de restreindre encore plus les caractères utilisables, aucun chef, si grand soit-il, ne viendrait nous em... avec des caractères à la c... Exemple : j'ai la liste de calques suivante 0 #calque #calque1 essai1 #texte si je fais un filtre de propriétés *#*, on s'attend a priori à ce que le filtre sélectionne tous les calques qui contiennent le caractère #. Que nenni ! On obtient la liste des calques qui contiennent un chiffre. Normal, c'est le job du joker # qui sait remplacer un caractère alphanumérique. On obteindra donc la liste 0, #calque1 et essai1 avec ce filtre. Si on veut vraiment la liste des calques qui contiennent #, c'est un peu plus compliqué : le filtre sera *`#*. Avec l'obligation d'utiliser l'apostrophe inverse (altgr 7) pour annuler le statut particulier du caractère spécial # et on aura la liste restreinte #calque, #calque1, #texte Amicalement Vincent

[quote (setvar "CLAYER" "#Textes") si le calque "#Textes" n'existe pas, le setvar ne va pas aboutir. Par ailleurs, si possible, évite d'utiliser des caractères spéciaux dans les noms de calques. Sinon, il y a longtemps j'ai fait cela Amicalement Vincent

Cela doit être la bonne explication. Par ailleurs, si on lance une commande ligne et qu'à la saisie du premier point on tape juste un chiffre puis entrée, ça fonctionne de la même manière. Pour le lisp, c'est de la grosse artillerie, effectivement, pour un besoin minime. J'avais fait tout d'abord un getpoint précédé d'un (initget "Milieu Répartis"). Quand l'utilisateur choisit "Répartis", il suit un getint qu'on arrive facilement à brider pour éviter les négatifs et les nuls. Mais comme l'utilisateur (moi...), ça l'ennuie de taper R puis un chiffre et voudrait taper le chiffre tout de suite, j'ai cherché une autre voie pour cela. Ce que j'ai retenu, c'est de faire un getpoint avec un (initget 128 "Milieu Répartis"). Soit c'est un point, soit c'est un mot clé ou un texte (qui peut être un nombre alphanumérique), soit c'est rien (-> option par défaut). Si le retour est un texte qui représente un chiffre positif et non nul, je sais continuer en sautant une étape. Si l'utilisateur a tapé autre chose que les mots clés permis par initget ou un chiffre positif non nul, j'aiguille vers l'option par défaut. L'utilisateur n'a qu'à faire attention, aussi ! Merci pour le retour d'expérience. Par ailleurs, je me sers toujours du bouquin lisp qui était fourni avec la version 12... Faudrait que je me mette à la page, car dans cette version, les bits de contrôle s'arrêtaient à 128 alors que dans les versions actuelles, cela va jusqu'à 1024 et je crois que je devrais m'intéresser au bit 256, mais je n'ai pas encore bien compris ce qu'il faisait

Bonjour, j'aimerai utiliser la fonction getpoint pour entrer, soit un point, soit des mots clés, soit un nombre entier positif non nul, soit rien (entrée par défaut) Pour la saisie du point ou d'un nul, pas de problème, c'est le job de base de la fonction getpoint. Pour les mots clés, pas de problème non plus avec (initget "Clé Key"). Par contre, getpoint n'est pas sensible aux bits de contrôle 2 et 4 de initget qui permettent respectivement d'interdire la saisie de zéro et de négatif, j'en conclue qu'il faut faire un contrôle a posteriori. Le problème est que si je saisis un chiffre à l'invite de getpoint, cela me renvoie un point. Commande: (getpoint) 1 (0.948636 0.31637 0.0) Je ne sais pas d'où sort ce point... Si on fait précéder le getpoint par un (initget 128), la fonction renvoie une chaine de caractères qu'on peut analyser. Commande: (initget 128 "Milieu Répartis") nil Commande: (getpoint) 1 "1" J'ai pensé que c'était un fonctionnement qui méritait d'être signalé. Par ailleurs, si les bits de contrôle 1 (pas de nul) et 128 (entrée arbitraire) sont activés, une entrée nulle renvoie une chaine de caractères vide. Commande: (initget 129) nil Commande: (getpoint) "" et pas "Point ou option nécessaire" avec un retour à l'invite comme on aurait pu s'y attendre. Mais l'aide indique que le binaire 128 et prioritaire sur le binaire 1, ce qui explique ce fonctionnement. Amicalement Vincent

Malgré tout, je continue à utiliser les 2 lisps ww et ii parce que je m'en sers depuis la version 12 (on est réactionnaire par nature...) et parce qu'ils partent du scg et aboutissent dans le scg. Quand on veut superposer des implantations lambert (par exemple), c'est quand même mieux. Les copier/coller, il faut faire attention d'où on part et où on va, si on manipule des scu autres que le scu général. Amicalement Vincent

Normal, chez nous, , l'entraide est chevillée au corps. Amicalement Vincent

On peut s'en passer sur les versions récentes, tout de même, en utilisant le copier/coller vers les coordonnées d'origine. Ce n'était pas le cas il y a 15 ans... Amicalement Vincent