bonuscad

Si je ne me trompe... D'après ce que j'ai compris VSMIN et VSMAX sont les limites qu'Autocad est capable de gérer à l'affichage sans provoquer de régénération de celui-ci. EXTMIN et EXTMAX sont les limites calculés par Autocad pour obtenir toutes les entités graphique à l'écran lors d'un zoom étendu, cela rejoint Tramber. Pour un zoom total, je crois bien que celui est géré par LIMMIN et LIMMAX. Passer par les variables que tu as citées sont en effet (à ma connaissance) le seul moyen.

Le point dans une liste à deux élément s'appelle une paire pointée. Les éléments qu'elle contient sont directement accessible par (car): 1er élément et (cdr): 2ème élément. A la différence d'une liste classique où le (cdr) ne te retournera pas un atome mais la liste du second élément. Donc c'est une manière de construire une liste à 2 éléments seulement, pour laquelle il sera très rapide d'accéder aux atomes. Pour une liste classique pour accéder au deuxième atome tu est obligé de faire (cadr '(1 2)) ce qui est la contraction de deux fonctions (car) et (cdr) alors que pour une paire pointée (cdr '(1 . 2)) suffira, ce qui sera plus rapide. Tu pourras remarqué que la plupart des données interne retourné par (entget) sont sous cette forme: (clé DXF . donnée)

J'ai pas trop suivi l'actu, moi ce que j'ai retenu, c'est surtout la spéculation des banques sur les matières premières qui font flamber les prix. Donc la source du problème n'est pas remis en cause, mais c'est le contribuable qui va payer grassement ces grands groupes financier. Nos chers dirigeants ne se mettent qu'à genoux en nous faisant croire qu'ils agissent pour notre bien... Au fait quand est t-il pour le fuel domestique, concerné aussi par cette baisse? Cela serait déjà un peu plus équitable, quitte à payer!

Bonjour, Il est dit dans l'aide d'Autocad: Effectivement avec un balayage, cela va beaucoup mieux, avec ton exemple je retrouve le balayage confondu au cercle.

Ah! désolé alors, pourtant ces profils sont bien pratique. Mais alors comment à fait cedmaximus

J'arrive trop tard... Je suis sur qu'un nouveau profil aurait largement suffit pour régler le problème. On suggère trop souvent une réinstallation/réparation. Pourtant générer un nouveau profil est vite fait et on retrouve ses petits rapidement. Pour moi une réparation est de dernier ressort, quand c'est vraiment la "bérézina" sur le PC.

Bonjour, Essayer peut être de changer la variable REMEMBERFOLDERS, mettre celle-ci à zéro ?...

Compliment à l'artiste, Un seul problème, qui n'est pas lié à ton code. Par exemple j'ai un type de ligne personnalisé utilisant une forme mais qui n'utilise aucune longueur de tiret, ex: A,0,-1,[FORME,forme.shx,x=0,s=1] à contrario d'un autre de cette forme: A,.25,-.1,[FORME,forme.shx,x=0,s=1],-.5,1 Et bien malgré ton code, pour la première définition je n'aurais pas une ligne continue mais des pointillés, ceci avec la version basique et la version avec réacteur. Mais bon y a que moi pour faire des définitions biscornues comme cela.

Je pratique Autocad depuis 86, personnellement je n'ai jamais rencontré entendu parlé de virus, tout au plus des farces de bidouilleurs avec les AutoCAD.lsp. Les malwares utilisant Autocad me semble assez récent. Je me suis amusé dernièrement à décortiquer sommairement (en pas à pas, je n'ai pas tout compris dans le code) un lisp douteux (écrit en vlax non compilé) de conception chinoise (malheureusement je ne retrouve pas le lien et je pensais l'avoir gardé quelque part; c'est toujours très instructif de voir ce genre de code), et bien en effet il cherchait bien à se dupliquer sauvagement dans tout les dossiers ouverts et/ou accessibles, la base de registre semblait vouloir être aussi attaqué: vu que je ne comprenait pas tout le code et par manque de temps, j'ai arrêté mon investigation. Après réflexion, j'ai effacé ce lisp car j'ai eu peur de conserver ce code en zappant son existence et sa gravité et de le propager par inadvertance (car comme dit plus haut, le problème est entre la chaise et le clavier et j'en fais partie) ;)

Salut Christian, Je ne pratique pas le diesel autant que toi (à vrai dire l'édition des boutons pendant les phases de test me gave un peu; l'ouverture du CUI est longue....) On avait eu déjà cette discussion ensemble. En regardant de nouveau les syntaxes incriminées (ici et dans mon lien), je me demande si cela ne viendrait pas de l'usage de $m=. J'ai l'impression que si celle ci est présente plusieurs fois dans la macro, seule la première est interprétée. Le problème avec le diesel, c'est que celui est un interpréteur de chaine de texte et non d'instructions littérales, cela fausse notre logique de conception.

Il est dit dans l'exposé: Il me semble qu'un script peut aussi être lancé de cette manière. (/s ou /sr de souvenir) Comme le dit Patrick Est ceci a duré de nombreuses années, sans qu'Autodesk bride sérieusement ses produits, la solution à été pénale et non technique. Pour moi ces problèmes de malwares sont surtout un problème entre la chaise et le clavier et de pseudo démocratisation de l'utilisation du logiciel (les messages concernant la bannière éducative en sont le révélateur, pour ne citer que ceux-ci...) Autodesk a choisi de rendre les données des dessins accessible par programmation, ce qui a contribué à l'attrait de celui-ci. Faire marche arrière devient difficile, donc le sparadrap reste de mise. Fait étrange, ces malwares coïncident avec l'apparition de logiciels concurrent. Les dessinateur ont-ils un intérêt à créer ce genre de code, si oui, pourquoi cela n'a pas t-il était fait avant? Ce sont pas des réponses, mais des réflexions.

Je ne peux pas tester, mais vu l'exposé, je me pose une question, quant est-il de l'exécution de script? Ce n'est pas du lisp, ni VBA ou autre langage, mais il me semble facile à travers un script de réactiver ces variables. Il y a aussi les réacteurs dans un DWG, bien que plus complexe, pourrait réactiver aussi ces variables. Le bout de sparadrap sur le bobo d'un enfant rassure toujours celui-ci, et là c'est l'impression que ça me fais...

Effectivement, moi aussi je ne me suis plus... Quand j'ai écrit la réponse, je pensais à la variable "CELTSCALE", mais en fait cela n'aurait aucune incidence vu le facteur appliqué à LTSCALE. Désolé de ce paragraphe de ma réponse complétement inapproprié et confus. Il faut dire qu'entre LTSCALE, CELTSCALE et PSLTSCALE j'ai moi même du mal à régler parfois mes type de ligne quand ces variables ont des valeurs folkloriques.

L'astuce de modifier l'échelle du type de ligne en valeur extrême (à la façon de _move pour mettre les Z à zéro) est peut être la méthode la plus simple. En tout cas elle fonctionnera bien si les types de ligne sont affectés aux calques, cependant si le type de ligne est affecté à l'objet seul et en plus avec sa propre échelle, cela ne sera pas suffisant pour résoudre le problème de sélection. J'ai rencontré des difficultés avec les fonctions lisp simulant une sélection manuelle par points (ssget), (nentselp) et aussi la fonction (osnap pt "mode d'accroche"), bien qu'elle simplifient la création d'un programme, elles ne sont pas toujours d'un comportement fiable d'une exécution à l'autre suivant le contexte. J'ai observé récemment aussi des retours aléatoire nul non justifié avec (vlax-curve-getClosestPoint) ou (vlax-curve-getClosestPointToProjection); ceci dans des systèmes de coordonnées générales avec des mantisse élevées (Lambert93 par exemple). Il y a certainement des solutions, mais ces cas extrêmes peuvent devenir un vrai cas-tête, difficile d'allier alors concision du code et efficacité avec fiabilité d'exécution de celui-ci... Quand on tombe sur les limites de calcul, soit c'est la bidouille, soit on laisse tomber ou dernière solution: on devient un génie de l'algorithme!

Et non... D'ailleurs même manuellement, tu remarquera qu'il est impossible de faire une sélection (pour effacement par exemple) en cliquant dans la discontinuité de la ligne. Par programmation, le seul moyen fiable (à mon avis) pour que la sélection réussisse est de faire une sélection globale de tes polylignes (ssget "_X" '((0 . "LWPOLYLINE"))), de traiter cette sélection pour lui affecter le style de ligne continu, en sauvegardant pour chaque entité de la sélection son type de ligne original. D'appliquer alors ta routine et en fin de celle-ci restorer les type de ligne de départ. Cela va compliquer beaucoup le code mais cela sera fiable. Dans un premier temps essayes quand même d'augmenter la variable "PICKBOX" dans ton programme avant de faire la sélection, autant bien cela peu suffire à résoudre ton problème. Si tu trouve la valeur pour PICKBOX qui te convient, assure toi d'avoir le même facteur de zoom sur ton dessin pendant l'éxecution car cela va influencer sur la zone de recherche de Pickbox. Avec cette variable cela restera quand même aléatoire pour la réussite de la sélection. AutoDesk aurait du faire une variable similaire à QTEXTMODE pour les type de ligne afin de d'établir un affichage de travail et un affichage de rendu. Peut être sont-ils à l'écoute?

Après coup, Je me rapelle de cette réponse, en mettant une couleur blanche (255,255,255) cela pourrait faire un plein et un vide?

Pour te compléter, le fichier .PLT peut être imprimé sans posséder aucun logiciel. A l'époque du DOS un: TYPE fichier.PLT > LPT1 , permettait de tracer le dessin vers un périphérique branché sur le port LPT1 et comprenant le langage HPGL. C'était pratique pour les imprimeurs qui ne possédaient pas forcément le logiciel Autocad, ou faire de l'impression par lots pendant la nuit depuis un PC dédié. Bien que toujours fonctionnels, les fichiers PDF sont maintenant préférés, les PLT sont obsolètes. Il existait même des routines lisp du genre HPGLin pour réimporter ces fichiers en temps qu'entités graphiques dans Autocad à la façon du DXB comme la commande _DXBin qui existe toujours.

Bonjour, Outre la réponse de Patrick_35 sur la définition du point d'insertion du bloc, il est vrai que les modes de sélection avec ssget autre qu'avec l'option "X" (pour tout) peut poser des problèmes suivant si les points de sélection sont hors écran, ou hors des limites de régénération actuel du dessin. Tu poses aussi le problème des type de ligne discontinu employé qui peuvent aussi être un frein pour la sélection. Donc pour ces modes de sélection avec points définis, il faut s'assurer en premier lieu que ces points soit dans l'espace graphique nécessaire, (en raccourci, je dirais aucune régénération de celui soit nécessaire pour afficher l'espace à exploiter). Pour les type de ligne, c'est plus délicat. Comme tu utilises le mode "Capture" ("_Crossing"), tu pourrais calculer des points de façon à faire une fenêtre élargie et non une capture sur un point unique comme tu l'as fait. Ou encore plus simplement tu pourrais faire ta sélection sur ton point point unique pt; ssget sans aucune option de sélection, juste fournir les coordonnée de ton point de sélection ex: (ssget pt '((0 . "LWPOLYLINE"))), mais en réglant la variable "PICKBOX" (valeur de 0 à 50) à une valeur élevée. Plus la valeur sera grande, plus les chances de sélectionner les type de ligne discontinu seront élevé aussi, (au risque de sélectionner aussi d'autre objets proches, à moins de faire un filtre plus sélectif : calque, type de ligne, couleur...). Voilà pour les piste que tu peux explorer.

On pourrait en déduire que c'est un problème de pilote de traçage... Il me semble que dans le paramétrage du traceur, à un moment il apparaît une option ou l'on choisit comment sont traiter les polices (suivant les types de traceur) soit elles sont traitées comme des polices (option par défaut), soit elles sont converties en bitmap. Il faudrait essayer cette seconde possibilité, cela risque d'augmenter le temps de traçage (puisque conversion), mais d'être plus fidèle si ton traceur ne comprends pas les polices ttf natives. De souvenir je crois que l'option, si disponible, se trouve dans la partie graphique de la configuration (plotter manager d'Autodesk) Voir aussi s'il n'y a pas une disponibilité d'une mise à jour de driver pour ton traceur. J'avais eu ce problème avec des HP mais pour du texte qui touchait le bord d'une fenêtre papier.

Ha mais oui c'est bien sûr !... Effectivement, je n'y avais pas songé, ça fonctionne mieux comme ça. Merci encore.

Bonjour thierry, et merci du tuyau Comme je viens de rencontrer le problème ce matin à l'ouverture d'un fichier, je viens de tester; sympa cet utilitaire. Donc dans un nouveau dessin, j'ai lancé l'utilitaire en sélectionnant le fichier incriminé. Il n'y avait pas grand chose concernant les AEC, juste: Je me suis mis dessus la clé et fais "terminé" car la case enregistrer dessin est resté grisée...??? (Covadis 12.0e)

Salut Steven, Du tout, ces fichiers ont été construit de A à Z par moi uniquement (Ils traitent l'ensemble d'un réseau routier départemental). Donc je ne comprends pas bien d'où vient la pollution. Par contre il est vrai que j'ai tenté au moins une fois (cela fais déjà un petit moment) d'ouvrir sur mon poste professionnel un fichier provenant Autocad Architecture et je me rappelle vaguement qu'à ce moment Autocad ma proposé de charger un truc style "enabler machin-truc" pour lire ce style de fichier, chose que j'ai accepté (j'ai peut être fais une erreur ce jour là). Toujours est-il que quand j'ouvre un fichier ou un xref dépendant qui me charge la base AEC je le passes aussitôt avec la routine de (gile) ;; RemoveAEC (gile) ;; Supprime tous les dictionnaires AEC du dessin (defun c:RemoveAEC () (foreach p (entget (namedobjdict)) (if (and (= 3 (car p)) (wcmatch (cdr p) "AEC*") ) (dictremove (namedobjdict) (cdr p)) ) ) (princ) ) J'enregistre le fichier de suite, puis le ferme et le ré-ouvre ensuite. Dans l'immédiat cela semble résoudre le problème. Mais sans comprendre pourquoi cette base réapparaît lors d'ouverture ultérieure (pas forcément de suite). Mais comme je l'ai dit précédemment j'ai beaucoup de fichiers dépendants et en plus il m'arrive de travailler avec des copies de versions antérieures stockées ailleurs (dès fois je m'y perds, où je travaille par inadvertance sur des copies sans m'en rendre compte à cause de l'historique d'Autocad) Il y a aussi ce sujet évoqué par SupportCova qui me fais craindre d'arriver à me débarrasser définitivement de cette base AEC. Je crois que je vais tenter un traitement en "batch" de tout mes fichiers ET copies et peut être les gabarits aussi... (j'vais pouvoir m'éterniser au café) :D Cette solution me gène un peu car j'ai beaucoup D'OD de Map et de Xdata et quelques champs dynamiques dans certains de mes fichiers, si je perds les éventuels AEC, je peu perdre aussi le reste...

Bonjour, Je me greffe sur le sujet. Je m'explique: je travaille avec Autocad Map et Covadis, cependant quand j'ouvre certain de mes fichiers, Autocad m'initialise la base AEC. Ma question est-ce normal ou suis je pollué par un quelconque fichier? Si cela n'est pas normal (je ne travaille pas avec Autocad architecture), comment dépolluer ces fichiers et comment repérer ceux ci, sachant que je travaille énormément avec des xrefs.

Tu peux essayer ceci my_project C'est une alternative qui ne traite que les objets filaires classiques. (LWPOLYLINE,POLYLINE,LINE,SPLINE,ARC,CIRCLE,ELLIPSE,POINT) Donc ne fonctionnera pas pour les blocs, des solides, des maillages, mais pour les entités énoncées, elle sera fiable et rapide en exécution.

Bonjour, Voici une macro de bouton (à bascule) qui permet de faire cela. Dans l'état elle géle/dégéle tous les calques, je te laisse l'adapter à ton cas précis: si cela reste possible, car je n'ai pas essayé... (à priori remplacer "*" par le "nom de ton calque" devrait suffire) ^C^C^P$M=$(if,$(=,$(getvar,useri2),1),'useri2;0;_.-layer;_thaw;*;;,'useri2;1;_.-layer;_freeze;*;;)^Z