bonuscad

Fait de même pour le lisp de X13 en version 2000 pour lui rendre service! (doit fonctionner pour les supérieures, mais aucun intêret) NB: ta variable "cord" ne sert plus à rien, mais c'est un détail.

Voilà la version qui devrait fonctionner sous une 2000 et plus (normalement) J'ai repris le code de gille pour l'espace objet, mais j'ai découvert une erreur que je n'ai pas corrigé. Gille se sert du sinus pour calculer la longueur, moi je me sert simplement de l'angle au centre en RADIAN et du rayon. En cas d'un arc commencant par exemple dans le 3eme quadrant et se terminant dans le 1er, le résultat est faux ! Donc je laisse corriger gille cet imperfction pour les versions 2002 et >. X13 il faudra corriger celui qui suit quand gille aura apporté la réponse. (defun c:dim_arc2000 ( / echo cot dxf_ent rad arc pt_pc ang_c pt_pe1 pt_pe2) (setq echo (getvar "CMDECHO")) (setvar "CMDECHO" 0) (princ "\nSélectionnez un arc ou un segment d'arc de polyligne: ") (if (eq (getvar "CVPORT") 2) (progn (command "_dimangular" pause pause) (setq dxf_ent (entget (entlast)) rad (distance (cdr (assoc 13 dxf_ent)) (cdr (assoc 15 dxf_ent))) arc (* rad (cdr (assoc 42 dxf_ent))) ) ) (progn (initget 1) (setq pt_m (trans (getpoint) 3 2)) (command "_.mspace") (setq dxf_ent (entget (ssname (ssget pt_m '((0 . "ARC"))) 0)) pt_pc (trans (cdr (assoc 10 dxf_ent)) 2 3) rad (cdr (assoc 40 dxf_ent)) ang_c (- (cdr (assoc 51 dxf_ent)) (cdr (assoc 50 dxf_ent))) arc (* ang_c rad) ) (if (< arc 0.0) (setq arc (+ (* 2 pi rad) arc))) (setq pt_pe1 (trans (polar (cdr (assoc 10 dxf_ent)) (cdr (assoc 50 dxf_ent)) rad) 2 3)) (setq pt_pe2 (trans (polar (cdr (assoc 10 dxf_ent)) (cdr (assoc 51 dxf_ent)) rad) 2 3)) (command "_.pspace") (command "_.dimangular" "" pt_pc pt_pe1 pt_pe2 pause) ) ) (setq dxf_ent (entget (entlast)) dxf_ent (subst (cons 1 (rtos arc 2 (getvar "DIMDEC"))) (assoc 1 dxf_ent) dxf_ent ) ) (entmod dxf_ent) (entupd (cdar dxf_ent)) (setvar "CMDECHO" echo) (princ) ) Lisp corrigé suivant indicaton de gille ;) [Edité le 10/8/2006 par bonuscad]

Avec la 2000, oui et non, le mode d'accrochage est possible depuis l'espace papier, mais pas la sélection d'objet. Et mon artifice ne convient pas tout à fait pour la suite de ta routine :mad: En effet tu récupère les infos de la fenêtre par (setq vp (cdr (assoc 331 (entget (cdr (assoc 330 e_lst))))) or par la création comme je l'ai proposé, cette info n'est pas récupérable (pas de code 331), en fait je tombe sur une entité "block_record" et non "viewport" :casstet: La solution pour x13? ne pas utilisé le facteur de la fenêtre, mais l'échelle par défaut de la cotation!...

Merci Gilles d'avoir continué le fil Oui j'étais parti sur cette optique, Fraid il serait bien d'ettayer tes souhaits par des images (avant/après), cela serait plus simple pour comprendre ce que tu veux faire exactement.

(vla-put-TextMovement obj_vla 2) dans la boucle (repeat ??

Après (vl-load-com) peut être une bonne place!

Constaté le même problème sous une 2000 :( En fait (command "_dimangular" pause pause) ne fonctionne pas sous une 2000 pour la sélection d'un objet dans l'EO depuis l'EP. pour pouvoir le faire dans le lisp, si on est dans l'EP il faudrait faire la sélection comme ceci pour remplacer la ligne incriminé. (le curseur n'a pas la forme de sélection d'objet !) (if (eq (getvar "CVPORT") 2) (command "_dimangular" pause pause) ;_ création d'une cote angulaire (progn (initget 1) (setq pt_m (trans (getpoint) 3 2)) (command "_.mspace") (setq dxf_ent (entget (ssname (ssget pt_m '((0 . "ARC"))) 0))) (setq pt_pc (trans (cdr (assoc 10 dxf_ent)) 2 3)) (setq pt_pe1 (trans (polar (cdr (assoc 10 dxf_ent)) (cdr (assoc 50 dxf_ent)) (cdr (assoc 40 dxf_ent))) 2 3)) (setq pt_pe2 (trans (polar (cdr (assoc 10 dxf_ent)) (cdr (assoc 51 dxf_ent)) (cdr (assoc 40 dxf_ent))) 2 3)) (command "_.pspace") (command "_.dimangular" "" pt_pc pt_pe1 pt_pe2 pause) ) )

Merci de m'avoir remémoré le post :exclam: Je l'avais déjà parcouru en diagonale, mais ce coup ci je l'ai gardé sous le coude pour pouvoir m'y référencer. J'ai du mal avec le style du vlax, beaucoup de chose obscures ...., mai ça viendra comme ca viendra. :P

Je suis pas très fort en vla, c'est mes premier pas, certainement à retoucher. Je suis reparti du lisp précédent.... Déjà revoir dim_rot pour faire un choix sur + ou - pi/2 ((lambda ( / js d n ent obj_vla pos_ac dim_rot new_pos) (setq js (ssget (list (cons 0 "DIMENSION") (cons 67 (if (eq (getvar "CVPORT") 2) 0 1)) (cons 410 (if (eq (getvar "CVPORT") 2) "Model" (getvar "CTAB"))) ) ) ) (cond (js (vl-load-com) (initget 1) (setq d (getdist "\nDonner la valeur de déplacement du texte de cote: ")) (setq n -1) (repeat (sslength js) (setq ent (ssname js (setq n (1+ n))) obj_vla (vlax-ename->vla-object ent) ) (setq pos_ac (vlax-safearray->list (vlax-variant-value (vla-get-TextPosition obj_vla))) dim_rot (+ (vla-get-TextRotation obj_vla) (/ pi 2)) new_pos (polar pos_ac dim_rot d) ) (vla-put-TextPosition obj_vla (vlax-make-variant (vlax-safearray-fill (vlax-make-safearray vlax-vbdouble (cons 0 (1- (length new_pos)))) new_pos ) ) ) ) ) ) (prin1) ))

Pour info plutôt "\n" par "\\P" Est ce que ce la fonctionne aussi pour > 2002 ?

En n'important pas l'objet "BLACK_MA1", tu pourras faire l'importation (incomplète bien sur, mais déjà tu en auras une grande partie) :D Même comme cela, il est déjà joli...

Je suppose que tu ais déjà allé, mais les notice proposé par T'nB en PDF concernant les DUO tout court, peut être que certaines manips sont similaire d'un modèle à l'autre ? DUO - VCR DUO - DVD J'ai une MELICONI (TV-SAT-VCR-DVD), malheusement y a toujours un appareil qui n'est pas reconnu J'ai abandonné l'usage de ces commandes universelles. :casstet:

Par développement on pourrait faire un truc comme ceci: Cela ne fonctionne qu'avec la pavé numérique et celui-ci étant en "NumLock". Cela pourait-il corespondre à ton souhait? ;48 = 0 ;...= ... ;57 = 9 ;43 = + ;45 = - ;42 = * ;47 = / ;46 = . ((lambda ( / pc dd) (setvar "cmdecho" 0) (while (and (setq key (grread T 4 0)) (not (member key '((2 13) (2 32))))) (setq pc (getvar "VIEWCTR") dd (* (getvar "VIEWSIZE") 0.125)) (cond ((eq (cadr key) 42) (command "'_.zoom" "_all") ) ((eq (cadr key) 43) (command "'_.zoom" "1.25X") ) ((eq (cadr key) 45) (command "'_.zoom" "0.75X") ) ((eq (cadr key) 46) (command "'_.zoom" "1") ) ((eq (cadr key) 47) (command "'_.zoom" "_extent") ) ((eq (cadr key) 48) (command "'_.zoom" "_c" (mapcar '(lambda (x y / ) (* (+ x y) 0.5)) (getvar "VSMIN") (getvar "VSMAX")) "") ) ((eq (cadr key) 49) (command "'_.-pan" pc (polar pc (* pi 0.25) dd)) ) ((eq (cadr key) 50) (command "'_.-pan" pc (polar pc (* pi 0.5) dd)) ) ((eq (cadr key) 51) (command "'_.-pan" pc (polar pc (* pi 0.75) dd)) ) ((eq (cadr key) 52) (command "'_.-pan" pc (polar pc 0.0 dd)) ) ((eq (cadr key) 53) (command "'_.zoom" "_c" (mapcar '(lambda (x y / ) (* (+ x y) 0.5)) (getvar "VSMIN") (getvar "VSMAX")) "1x") ) ((eq (cadr key) 54) (command "'_.-pan" pc (polar pc pi dd)) ) ((eq (cadr key) 55) (command "'_.-pan" pc (polar pc (* pi 1.75) dd)) ) ((eq (cadr key) 56) (command "'_.-pan" pc (polar pc (* pi 1.5) dd)) ) ((eq (cadr key) 57) (command "'_.-pan" pc (polar pc (* pi 1.25) dd)) ) ((eq (car key) 2) (princ " *** Touche non valable! *** ")) ) ) (setvar "cmdecho" 1) ))

Cela serait bien de savoir si des XRefs on été déplacer (ou dossier renommé) de manière manuelle. De savoir aussi le degré d'imbrication de ceux-ci, et le mode d'enregistrement du chemin de ceux concernés (complet/relatif), si des reférences réseaux existe, le mode de reconnection de windows a ces chemins UNC à chaque session (c'est un portable déconnecté ?) Je pense que si conditions peuvent être remplies, il peut y avoir des lenteurs, plantages, lors de recherche (surtout en réseau). C'est une demande d'infos complémentaires ou une piste à explorer pour identifier le problème. :casstet:

Et on pourrait fixer la barre encore plus haut ! :exclam: En effet je penses que, comme certains, on a tous voulu créer ce genre de fonction pour l'ajustement automatique. On commmence par un truc tout simple, et au fur et à mesure, on voit les limites du code qu'on a créé et on essaye de modifier en conséquence (j'tdis pas l'histoire sans fin! ) ;) Ici le plus gros "Hic" c'est quand on veut que cela soit valable avec les arcs. Le code proposé fonctionnera dans ce cas ci avec les cordes des arcs, donc dans des cas complexes certain objets vont mal réagir, ou pas comme on veut. On est alors confronté à la résolution de défintion des arcs. Certain on résonné avec les longueurs fixe d'arc pour créer les points suffisant pour créer la sélection. Pour ma part je pense qu'il vaut mieux le faire soit, par une division fixe de la longueur de l'arc concerné, ou par balayage angulaire, ceci pour avoir toujours le même nombre de points quelque soit la grandeur utilisé pour l'arc ou l'unité utilisé. (la définition de la partie fixe, ou d'ouverture d'angle fixera la présicion de la routine et sa fiabilité ET sa rapidité.) A une époque "Miamar" avait voulu éplucher la fonction extrim des express tools par un sujet ou j'avais essayer de l'aider. On constate aussi que Extrim est confronté à ce problème de résolution des arc.

1 ans après, j'ai essayer d'évoluer sur ces fonctions (vlax-curve Si je les trouve puissantes, rapides et fournissant un code compact, je reste cependant découragé par leur emploi. Je n'arrête pas de trouver des différences de comportement suivant la version ou elles sont utilisées. Je trouve cela vraiment très ennuyeux de ne pas pouvoir produire un code qui soit utilisable quelque soit la version utilisé. (200X) En lisp classique ce problème était très rare, les codes pouvaient s'utiliser (s'il étaient bien montés) d'une version à une autre sans surprises. Ce manque d'homogéité est quand même décourageant pour les développeurs qui aimeraient bien pouvoir créer du code qui soit facilement exploitable et pas seulement rataché à une version unique (ou presque). C'est surtout le manque de transparence qui me gène, car jamais il n'est stipulé nulle part ces changements effectués sur les modes de fonctionnement. On a l'impression que c'est pareil qu'avant et en fait on découvre avec le temps qu'il n'en est rien (que d'heures perdues en pure perte!) Voilà c'etait juste mon petit coup de gueule, mais le problème est toujours là. Donc développeurs, il va falloir en plus de vos gestions d'erreurs penser à verrouiller vos applications suivant la version unique sous laquelle elle est créée, j"exagère à peine !!!

Relire ce Sujet serait pas mal non plus :exclam:

Peut être ce SUJET déjà évoqué ? Oops pardon, j'avais pas vu que c'était sur un forum LT. [Edité le 2/8/2006 par bonuscad]

Jettes un oeil ICI Solution en free, pas simple à mettre en place et à utiliser, mais donne de bons résultats en DXF pour des PDF générés depuis Autocad en vectoriel.

Merci au Décapode "Service Packant" Tous les patchs étaient bien appliqués, par acquis de conscience j'ai réappliqué ceux-ci. En effet aucune correction pour ce problème précis qui persiste. Pour moi cela n'a pas une importance majeure vu l'utilisation de ce poste dédié à une tache précise. L'info est quand même bonne à savoir pour ceux qui pourrait être concernés, doivent pas être nombreux.... :P

Nickel ! Je confirme. A partir d'une 2002 ça fonctionne correctement. Sous une 2000 cela confirme mes soupçons sur le comportement bizarroîde des fonctions (vlax-curve) Le Crabe pourra peut être me dire si j'ai raté un pacth qui corrigerai ce problème de compatibilité entre version? Mais bon l'importance est minime; les versions 2000 en cours ne sont pas légion.

En effet: +1 pour toi ;) Sur des polylignes2D classiques dans un SCU non parralèle, pas sous une V2000. :( Je testerais sous une 2002 et 2005 le plutôt possible. (je croise les doigts pour que ça fonctionne) En tout cas bravo pour ta fonction (osnap "_near") en vlax qui rendra service en construction 3D pour des entités mesurables avec les fonctions vlax. Tu vas devenir le "pro" de la programmation en 3D, tous mes encouragements ;)

Fonctionne beaucoup mieux. Après une série de test, seules les Polylignes2D dans un scu (non parrallèles au scg) donnent un résultat incorrect, pour des LwPolylignes c'est bon. Mais tu cherche à résoudre peut être un problème insoluble, car le (osnap pt "_near") coince aussi sur ce genre d'entité dans les mêmes conditions. Donc match nul ;) Ma solution (pas élegante) a été de convertir ces polylignes en lwpolylignes et de refaire (osnap pt "_near") sur celle-ci. J'essayerais quand même ta solution sous d'autres version dès que possible, car les fonctions (vlax-curve-...) réservent quelque fois des surprises suivant la version! :casstet: Le pire observé est surtout entre une 2000/(i) et supérieures. La 2000 n'est pas aboutie sur ces fonctions (vlax-curve-..). Suivant comment le code est monté, on a droit à des erreurs, ou des résultats "fantaisistes".

Peut être une solution ICI ? Jamais eu l'occasion de l'utiliser ! Quand j'ai besoin j'utilise DBTRANS sous une 2002.

Merci Giles de ta suggestion. J'ai bien essayer d'appliquer ta proposition, mais ça ne fonctionne pas toujours comme je le desirerais, ceci avec des LwPolylignes ou Polylignes2D dans des SCU non parrallèles. NB: j'ai remplacé ucszdir par (trans '(0 0 1) 1 0 T), nous sommes bien d'accord ? Les points obtenu sont à "perpètes" :casstet: Donc pour l'instant je reste sur ma solution, qui n'est pas très élégante, mais fonctionne. J'essayerais de mieux comprendre la fonction que tu as voulue faire à tête reposée ;)