Modifier nombre de décimales pour toutes les instances d'un attribut

[brunomu]

Bonjour le Forum !

 

Je travaille sur un gros fichier qui inclut des attributs où figure la surface de polylignes.

Malheureusement cet attribut a été défini avec 2 décimales, ce qui est un peu ridicule. Un chiffre après la virgule suffirait, voire un arrondi à 0,5 près (donc 50m² ou 50,5m² ou 51m²).

 

Problème : j'arrive à corriger ce paramètre (pas l'arrondi à 0,5 près) sur chaque attribut, mais pas sur plusieurs attributs à la fois.

 

Faut-il passer par du LISP (mais je ne sais pas faire) ou y a-t-il une commande que j'ignore ?

 

Merci à qui saura me répondre !

[lecrabe]

Hello

 

Un reponse en mode Vitesse Grand V :

 

En supposant que tes blocs sont des blocs classiques (cad NON dynamiques & NON parametriques)

et que tu as les routines Express/Bonus installees et operationnelles :

- ATTOUT

- Tu traites la colonne concernee sous Excel et tu ne touches a RIEN d'autre !

- ATTIN

 

Et ca devrait faire ...

 

Bye, lecrabe

[brunomu]

Bonjour,

 

Merci pour ta réponse.

Ça fonctionne...en surface. C'est-à-dire que les valeurs reviennent d'Excel au bon format, mais les champs deviennent du texte.

Donc si je modifie une polyligne, sa surface n'est plus mise à jour.

 

Je crois que devant la complexité, je vais en rester à mes 2 décimales...

[lecrabe]

Hello

 

Desole mais j'avais compris que tu avais des textes simples dans des attributs de bloc

qui "reflétaient" la surface des polylignes !

 

En fait tu dois avoir des attributs (de bloc) qui sont en fait des champs dynamiques associes a la polyligne concernee !!

 

Bye, lecrabe

[Patrick_35]

Salut

 

Et avec la commande UNITES ?

 

@+

[brunomu]

@le crabe :

 

En effet, je n'avais pas décrit assez précisément mon problème : il s'agit bien d'attributs de blocs contenant des champs dynamiques associés à une polyligne.

 

 

@Patrick_35 :

 

Bien tenté, mais ça ne marche pas :(

 

 

 

...et @ tout le monde : si vous avez une idée...

[(gile)]

Salut,

 

Le nombre de décimales fait parti de l'expression de champ (%pr2 pour deux chiffres dans l'exemple ci-dessous) :

%%).Area \f "%lu2%pr2">%

Si tu mets en ligne un bout de dessin (dans un ZIP) avec ce bloc ou si tu donnes le nom du bloc, celui de l'attribut ainsi que l'expression de champ concernée, on doit pouvoir faire quelque chose en LISP.

[VDH-Bruno]

Bonjour,

Malheureusement cet attribut a été défini avec 2 décimales, ce qui est un peu ridicule. Un chiffre après la virgule suffirait, voire un arrondi à 0,5 près (donc 50m² ou 50,5m² ou 51m²).

 

En quoi est-ce ridicule 2 décimales? Que cela ne te conviennent pas je peux le comprendre, après il faut savoir que dans certains corps de métier, si on part du principe que l'unité (m, cm, mm) est fonction du projet, par convention le nombre de chiffre significatif pour la partie décimal est fonction de la dimension:

- 1 décimale pour les longueurs

- 2 décimale pour les surfaces

- 3 décimale pour les volumes

 

A+

[brunomu]

Re-

 

@(gile) : merci pour ta proposition, c'est très sympa.

Je joins un bout de plan zippé.

extrait.zip

[brunomu]

@VDH-Bruno

 

OK, mon qualificatif de valeur peut paraître abrupt.

 

Pour l'éclairer : je travaille sur l'esquisse d'un projet à ≈ 45M€.

Le projet comprend des locaux allant de 3 à 1500m².

Au stade esquisse, afficher des surfaces de pièces en m² avec 2 décimales parait naïf, alors qu'il s'agit des grandes lignes d'un projet encore à définir.

Il est plus approprié d'arrondir au m² près, voire à 0,5m² près.

 

Plus tard dans les études, on peut indiquer les surfaces avec 1 décimale.

Avec 2 décimales à mon avis, on est dans du théorique, parce que concrètement, il faut commencer à se demander si on décompte les plinthes, etc... Perso, une décimale me suffit, mais chacun fait à son idée.

[(gile)]

Ça a été moins facile que je pensais.

Curieusement avec Visual LISP (interface COM), on ne peut pas atteindre le code de champ d'un attribut alors qu'on peut le faire avec un texte. J'ai donc dû chercher assez profond dans les codes DXF.

 

Le LISP ci-dessous est très spécifique : il ne fonctionnera qu'avec les attributs "SU" des blocs "ETIQUETTE" tels que dans le dwg que tu as mis en ligne.

 

(defun c:brunomu (/ ss n blk att elst code)
 (if (setq ss (ssget "_X" '((0 . "INSERT") (2 . "ETIQUETTE"))))
   (repeat (setq n (sslength ss))
     (setq blk	(ssname ss (setq n (1- n)))
    att	(entnext blk)
     )
     (while att
(if (= "SU" (cdr (assoc 2 (setq elst (entget att)))))
  (progn
    (setq elst (entget
		 (cdr
		   (assoc
		     360
		     (entget
		       (cdr
			 (assoc
			   360
			   (entget
			     (cdr
			       (assoc
				 360
				 (entget
				   (cdr	(assoc 360 elst)
				   )
				 )
			       )
			     )
			   )
			 )
		       )
		     )
		   )
		 )
	       )
	  att  nil
	  code (assoc 2 elst)
    )
    (entmod
      (subst
	(cons 2 (vl-string-subst "%pr1" "%pr2" (cdr code)))
	code
	(subst '(300 . "%lu2%pr1") '(300 . "%lu2%pr2")
	  (subst '(301 . "" ) (assoc 301  elst) elst)
	)
      )
    )
  )
  (setq att (entnext att))
)
     )
   )
 )
 (command "_regen")
 (princ)
)

[brunomu]

Wow !

 

Merci pour tout ce boulot.

 

Cela dit ça ne marche pas sur mon poste (ACAD 2013 fr sous Win 7 PRO).

 

Dès que je tape le nom du LISP, j'obtiens un message d'erreur :

; erreur: type d'argument incorrect: lentityp nil

 

Des idées sur ce qui cloche ?

[(gile)]

Salut,

 

Chez moi, la routine fonctionne bien avec AutoCAD 2013, Windows 7 64 bits et l'extrait de dessin fourni.

Comme je le disais dans mon message, la routine "ne fonctionnera qu'avec les attributs "SU" des blocs "ETIQUETTE" tels que dans le dwg que tu as mis en ligne." Si le contenu de certains attributs du dessin complets ne sont pas des champs au format identique à ceux de l'extrait, il est normal que ça ne fonctionne pas...

 

Tu peux essayer le code ci-dessous qui devrait ne pas bloquer sur les attributs non conformes (il ne seront pas traités bien sûr).

 

(defun c:brunomu (/ ss n)
 (if (setq ss (ssget "_X" '((0 . "INSERT") (2 . "ETIQUETTE"))))
   (repeat (setq n (sslength ss))
     (vl-catch-all-apply
'(lambda (/ blk att elst code)
   (setq blk (ssname ss (setq n (1- n)))
	 att (entnext blk)
   )
   (while att
     (if (= "SU" (cdr (assoc 2 (setq elst (entget att)))))
       (progn
	 (setq elst (entget
		      (cdr
			(assoc
			  360
			  (entget
			    (cdr
			      (assoc
				360
				(entget
				  (cdr
				    (assoc
				      360
				      (entget
					(cdr (assoc 360 elst)
					)
				      )
				    )
				  )
				)
			      )
			    )
			  )
			)
		      )
		    )
	       att  nil
	       code (assoc 2 elst)
	 )
	 (entmod
	   (subst
	     (cons 2 (vl-string-subst "%pr1" "%pr2" (cdr code)))
	     code
	     (subst '(300 . "%lu2%pr1")
		    '(300 . "%lu2%pr2")
		    (subst '(301 . "") (assoc 301 elst) elst)
	     )
	   )
	 )
       )
       (setq att (entnext att))
     )
   )
 )
     )
   )
 )
 (command "_regen")
 (princ)
)

[brunomu]

Bonjour,

 

Tout d'abord merci pour ta persévérance.

 

Il y a du mieux : au lieu de me renvoyer un msg d'erreur dès que je tape le nom de la commande, je n'ai plus de msg d'erreur.

En revanche, la commande se termine aussitôt, sans rien changer au fichier semble-t-il, et sans me demander aucune action...

[-Olivier-]

Bonjour brunomu, comme le précise à plusieurs reprise le programme ne fonctionne uniquement pour les fichiers contenant des blocs dont le nom est ETIQUETTE ET avec au minimum un attribut SU.

 

Le programme fonctionne chez moi sans problème avec le fichier que tu as fourni. Si ta demande est différente alors il faut le préciser.

 

Olivier

[brunomu]

Bonjour,

 

Merci pour la précision, mais normalement ça devrait marcher : pour envoyer le fichier "extrait.dwg", j'ai juste fait un wbloc d'une partie du plan sur lequel j'essaie de faire fonctionner le LISP...

 

Mystère.

[brunomu]

Rétropédalage :

je viens de redémarrer mon ordi, de rouvrir le fichier, de relancer le LISP : ça marche !

Je ne sais pas ce qui n'avait pas marché jusque là...

 

Merci à tous ceux qui m'ont aidé. Mention spéciale à gile.