zebulon_

Bonne nouvelle. Un autre moyen pour les possesseurs de vieilles licences Autocad de récupérer le fichiers 2004 qu'ils reçoivent. C'était une évolution programmée de BDC ? Ou est-ce une réaction à la sortie de DWG gateway ? Amicalement Zebulon_

Salut Gilles, je vois que tu as persisté dans la bidouille lisp et ça me fait plaisir. Bienvenu sur ce forum, mais arrête de prendre les québecois pour des marseillais. Le saint laurent, c'est pas la méditerranée que je sache ... Excuse le x13, la géographie n'a jamais été son point fort. Amitiés Zébulon_

Salut, on ne peut pas laisser un alsacien dans le pétrin. Ton problème à l'air de venir du fait que entnext n'est fait qu'une seule fois. Si ton bloc a plusieurs attributs il faut faire des entnext autan de fois que nécessaire pour trouver le bon attribut ou bien tomber sur SEQUEND quand il n'y en a plus. Du genre : (setq e (ssname ss n)) (setq a (entget e)) (while (/= (cdr (assoc 0 a)) "SEQEND") (if (= (cdr (assoc 0 a)) "ATTRIB") (progn (setq NOMATT (cdr (assoc 2 a))) ..... ) ) (setq e (entnext e)) (setq a (entget e)) ) Si on n'a pas besoin de passer en revue tous les attributs, on peut aussi imaginer faire arrêter la boucle while quand on a trouvé le bon attribut. Bye

Salut, Toute la série des defun s1, s2, s3 qui se ressemblent beaucoup, mériteraient d'être simplifiée et regroupée dans une seule fonction avec des paramètres, cela réduirait grandement la longueur du code. amicalement Zeb

Serge apporte le sirop d'érable, moi j'apporte la bière Fischer de schiltigheim (celle que Tramber préfère) et on va pouvoir tester une variante à l'apéritif préféré des alsaciens (à savoir le picon bière) en goutant un cocktail sirop d'érable + bière. La recette : 2 doigts de sirop d'érable + 25 cl de fischer (le tout à consommer avec modération, comme il se doit, l'abus d'alcool est dangereux). Certains préfèreront avec un peu de jus de citron, mais pas les puristes... Maintenant, il faut encore trouver un nom à ce cocktail : - un Tramber Spécial ? - un Alsacadien Dry ? à vous pour de nouvelles propositions ... Amitiés Alsaciennes Zeb

J'ai dit "essayer". Ce sera donc dans la mesure de mes faibles moyens. Je ne m'appelle pas Jésus et ne veux pas convertir la terre entière. De toute façon je n'y arriverai pas. Mais bon, si chacun y met un peu du sien ... Je suis tout de même content qu'il y en a au moins un ou deux dans le lot à partager mon avis. Deux de moins à convertir ... Zeb, le pape du .stb, vous souhaite une bonne journée Amicalement

Pfff Si même les jeunes sont d'un conservatisme thatchérien, je perd espoir en l'avenir ... Quant à dire que le .stb est plus compliqué, je ne suis pas d'accord. C'est différent, c'est tout. Et puis si l'on reçoit un fichier .dwg de l'extérieur, qu'il soit en .stb ou en .ctb, si on ne reçoit pas le fichier .stb ou .ctb avec, on n'en fait pas grand chose quant il s'agit de l'imprimer. Amiicalement Zeb

Ouahh !!! je ne sais pas si mon sondage à une valeur, compte tenu du nombre de réponses, mais j'ai bien peur qu'il y a encore du boulot avant que le .stb se généralise... Au fait, moi j'ai 39 ans, j'ai commencé la DAO en 1990 sur Microstation pour continuer en 1992 sur Autocad. Pour la petite histoire, à l'époque sur Microstation sévissait la même règle : une couleur = une plume, mais sur microstation on avait déjà la possibilité d'affecter une plume à une épaisseur, si, si ... Merci, pour votre participation. Contre vents et marées, je vais essayer de démocratiser le .stb Amicalement Zeb

Bonjour Je fais partie de ceux qui ont commencé à utiliser Autocad avant la chute du mur, du temps où je n'avais pas encore les cheveux gris (mais bon, il m'en reste, des cheveux, contrairement à d'autres ...). A l'époque, on ne se posait pas mille questions sur la façon de tracer : une couleur = une plume, point à la ligne. Je me suis concocté une méthode en fixant que 1 calque = 1 plume, donc que 1 calque = 1 couleur. Comme je n'utilise que 4 ou 5 plumes, les calques ont souvent les mêmes couleurs. Quand les .stb sont sortis, je ne me suis même pas demandé ce que c'était, puisque le .ctb fonctionne "comme de dans le temps" et que je n'avais pas envie de me casser la tête avec une nouveauté (qu'est ce qu'on peut être réactionnaire, c'est affollant !!!) Or, en y regardant de plus près, le .stb s'adapte parfaitement à ma façon de faire, puisque à chaque calque on peut affecter un style, donc une plume. Du coup, je m'en veux de n'avoir pas été curieux plus tôt, parce que je ne vois que des avantages à utiliser le .stb. Ce serait amusant de faire un sondage : qui utilise le ctb ou les stb, en fonction de leur âge ? Amicalement Zeb

Merci pour ta proposition, Tramber. Je ramène la bière et les sandwiches... et d'ici là, bonnes vacances ? Ou bien tu as trop de boulot ?

Merci pour vos réponses. Je pense que je vais investir et m'investir dans ObjectDCL et construire sur mon acquis en lisp. Dot Net, je ne connais pas... mais je ne veux pas m'investir à savoir piloter un airbus pour finalement faire voler un cerf-volant

Compétitionner, je me doutais bien que cela voulais dire quelque chose comme concurrencer, mais j'avais peur de me tromper...

Salut Serge, Peux-tu éclairer ma lanterne : compétitionner ça peut se traduire comment ? Zebulon

Maginifique de pouvoir décrire une boîte de dialogue de façon graphique et non plus liittérale comme avec DCL. On n'est pas des écrivains, ça se saurait, on est des dessinateurs, alors vive ObjectDCL. Sans compter les possibilités que DCL n'offre pas : prévisualiser des fichiers dwg, afficher des images bitmap, choisir la police du texte etc... Voilà une bonne idée qu'Autodesk pourra "reprendre" pour la version 2007 [Edité le 9/6/2005 par zebulon_]

Bonjour à tous, j'ai téléchargé une version d'ObjectDCL (www.objectdcl.com). Je ne sais pas encore le faire fonctionner mais, compte tenu de ce qui est décrit dans l'aide, je crois que je vais mettre mon bon vieux DCL à la retraite. Car comme disait Didier, pour mémoire "DCL" signifie : Dramatique Comme Langage !!! http://www.cadxp.com/sujetXForum-2000.htm Sinon, s'il y a des utilisateurs d'ObjectDCL, quel est votre avis sur le produit ?

Mais tel c'est écrit, j'ai l'impression que constituant_id ne devient nil que quand tu arrives à la fin du fichier et non à la fin de la définition du block ???

Je n'ai pas tout bien compris, mais moi quand je veux dépiauter un bloc, je fais une boucle while jusqu'à tomber sur SEQEND (setq bloc_prop (tblnext "block" T)) (while bloc_prop (setq constituant_id (cdr (assoc -2 bloc_prop))) (setq AC (entget constituant_id)) (while (/= (cdr (assoc 0 AC)) "SEQEND") .... (setq constituant_id (entnext constituant_id)) (setq AC (entget constituant_id)) ) (setq bloc_prop (tblnext "block")) ) en résumé, d'abord je défile la liste des blocs dans la table des blocs, puis pour chaque bloc je dépiaute chaque élément avec une autre boucle while. A propos des blocs, les xrefs sont définis comme des blocs, ne faudrait-il pas les exclure ??

oui, mais certains croient que parce qu'on utilise la CAO, on peut changer le projet comme on veut. On n'a plus besoin de gratter, donc c'est fastoche de tout changer ... Ceux qui croient ça n'y connaissent rien à la CAO. Faire, défaire, refaire, c'est toujours [surligneur] faire[/surligneur]. Et ce n'est pas parce que c'est fait en CAO que ça se fait tout seul. Quand arrivera le jour où on pourra faire juste du premier coup... Cela me fait penser à l'évolution qu'ont connu les ingénieurs. Autrefois (du temps des dinosaures), avant de commencer le calcul d'une structure, ils réfléchissaient bien au problème en amont et après se lançaient dans le calcul. Maintenant, ils modélisent, font calculer et regardent les résultats. Si les résultats ne sont pas bons, ils modifient et font recalculer jusqu'à trouver un résultat satisfaisant.

Je viens de m'apercevoir d'un détail intéressant : l'utilisation de la variable doit respecter la casse. (setenv "maxhatch" "100000") ne fonctionne pas, il faut absolument taper (setenv "MaxHatch" "100000")

Juste pour ma culture personnelle, avec la LT on peut taper (setenv "maxhatch" "100000") ?

Je ne maîtrise pas les réacteurs. J'ai consulté l'aide qui concerne la fonction vlr-mouse-reactor et il me semble que les événements qui sont détectés par ce réacteur sont le double clic et le clic droit. Les événements qui m'intéresse serait le clic gauche et le fait de juste faire de bouger la souris. Mais bon, comme je n'y connais pas grand chose avec les réacteurs, je raconte sans doute des salades ...

Merci Bonuscad Poussé par la curiosité, je suis allé voir un peu le code que tu me proposes. Au niveau de la simulation des accroches objet, j'ai vu que c'est le lisp qui impose la taille et la couleur du marqueur de snap. Je te propose d'utiliser les préférences définies dans autocad. A ce propos, j'ai une fois cherché les variables autocad qui pouvaient stocker ces informations, sans succès. Du coup je me suis tourné vers visual lisp pour trouver mon bonheur. (vl-load-com) (setq b (vla-get-drafting (vla-get-preferences (vlax-get-acad-object)))) (setq OSNAPCOL (vla-get-AutoSnapMarkerColor b)) (setq OSNAPSIZE (vla-get-AutoSnapMarkerSize b)) à toutes fins utiles ...

Justement et comme tu dis ce n'est que pour faire joli. Alors, s'il faut pour ça se farcir 15 pages de code, je crois que je ferai moins joli. Mais bon, j'avais un faible espoir que visual lisp nous ai concocté une fonction vla-getdynpoint ou quelque chose du même tonneau. Je ne perd pas espoir, mais il s'amenuise....

Ce n'est pas le fonctionnement de getpoint qui me gène c'est celui de grread. En fait, ce que je cherche c'est un "getdynpoint" qui renvoie les coordonnées d'un point soit quand on clique sur le bouton de gauche de la souris, soit quand on bouge la souris sans cliquer quoi que ce soit. Le fait de cliquer sur le bouton de droite ferait arrêter la boucle while (voilà le but précis) La fonction grread sait faire cela, mais elle perd les accroches objet et tout le reste... Alors ce que je cherche, c'est une fonction qui sait renvoyer les coordonnées d'un point juste en bougeant la souris (de façon dynamique, si l'on veut) et qui soit un peu plus "intelligente" que grread. à titre d'exemple, voici un petit lisp qui utilise grread, tu verras que plus rien ne fonctionne en matière d'entrée de données utilisateur. Si le but est de cliquer quelque part au pif, grread est ce qu'il nous faut. Si le but est de cliquer quelque part de précis (extrémité, milieu ...) ou de donner les coordonnées, ou lancer une commande transparente, ça se gâte... (defun dessin_provisoire () (redraw) (grdraw PT0 PT1 -1 1) (grdraw PT1 (polar PT1 (/ PI 4) (distance PT0 PT1)) -1 1) ) (defun dessin_definitif () (command "_line" PT0 PT1 (polar PT1 (/ PI 4) (distance PT0 PT1)) "") ) (defun c:testgr () (setq PT0 (getpoint "\nSaisir premier point : ")) (setq PT1 PT0) (princ "\nSaisir deuxième point : ") (setq FLAG T) (while FLAG (setq CODE_RET (grread 1 7 0)) (setq TYPE_RET (car CODE_RET)) (cond ((= TYPE_RET 5) ;; Elément de saisie graphique (setq PT1 (cadr CODE_RET)) (dessin_provisoire) ) ((= TYPE_RET 3) ;; Point sélectionné (setq PT1 (cadr CODE_RET)) (setq FLAG nil) ) ) ) (redraw) (dessin_definitif) ) amitiés alsaciennes [Edité le 18/4/2005 par zebulon_]

Salut, je pense que le problème réside dans le nombre d'éléments qui constituent la hachure. Plus ta zone de hachure est grande et plus ton échelle est petite, plus le nombre d'éléments qui constituent la hachure est grande. Et ceci jusqu'à dépasser une certaine limite qui fait en sorte de ne plus afficher la hachure. 3 solutions : - ne plus hachurer qu'avec le motif SOLID en prenant comme référence la couleur; - au lieu de faire une grande zone à hachurer, en faire 3 ou 4 plus petites - augmenter la limite dont je parle ci-dessus mais (setenv "maxhatch" "n") ne doit pas marcher avec la LT, donc il ne reste plus que la solution qui consiste à utiliser regedit et modifier la variable d'environnement directement dans la base de registres ???