alala

Exactement ce dont je voulais parler, pour moi elle devient presque invicsible (en plus d'être étrangement flotante). J'ai tellement l'habitude d'avoir 3 à 5 lignes visible en plus de la ligne d'écriture que cette ligne unique en devient "dérangeante". Enfin il faut bien évoluer et si l'interface va vers une meilleure ergonomie c'est peu être à nous (moi) de faire l'effort d'adaptation necessaire.

La zone de texte est caché dans les interfaces de base maintenant (sous Map 2013 c'est le cas), par contre les commandes au claviers ne sont pas prêtes de disparaitre, ce serait la plus grosse erreurs qu'Autodesk puisse produire. Pour la complétition automatique j'avais effectivement oublié ce fait sur les nouvelles versions, c'est un vrais plus.

Seul soucis du clavier depuis quelques années, la complétition des noms des commandes avec TAB (pratique quand on veu pas se tapper tout une nom de commande sans toucher aux raccourcis) des commandes sont de plus en plus longues à charger la première fois. Et j'ai l'impression qu'Autodesk s'oriente vers une disparition visuelle de la fenetre de texte. Reste qu'effectievement il est largement plus simple d'écrire ou de dire une commande que de l'indiquer via une icône ou un chemin de menus. D'ailleur il n'y à qu'a regarder l'aide pour vite comprendre que c'est même dificile pour Autodesk car ces menus différents suivant les gouts de chacun et les version du produit.

Oki pour le multicoeur au dessus de 4 ça fonctionne donc comme il faut, j'avais soit un mauvais souvenir soit ça a évolé sur les versions suppérieurs à 2011. Ce qui est dommage dans tout cela c'est que le Multithread n'est utilisé que dans peu de cas, hors on aimerait avoir tout le logiciel qui en profite et pas uniquement le rendu et 2/3 fonctions.

Oui, Autocad gére le multithread en multicoeur, mais PAS en multiprocesseurs! Donc un processeur à plusieur coeurs c'est top, plusieurs processeurs avec moins de coeurs c'est innutile! Et si ça n'a pas changé au dessus de 4 coeurs Autocad ne gére plus!

Bonjour, Je tape énormément de commandes au clavier. J'utilise peu les menus (que je trouve mal structurés), et pas du tout les Ruban. J'utilise donc principalement la ligne de commande, les barres d'outils et les palettes d'outils (agencés pour coller au plus près de notre gabarit de travail). je constate personnellement une très faible utilisation des Ruban chez mes collègues dans différentes sociétés, il y a un rejet de presque tous les utilisateurs, et même si ils apportent quelques plus non négligeable j'admet ne pas y voir beaucoup d'avantages qui me feraient changer pour eux (et j'avoues avoir développé une petite allergie à ces ruban quand ils ont été imposés sur Revit ce qui a entrainé une grosse perte d'ergonomie). Je pense que les "jeunes" sur Autocad utilisent plus les Ruban car c'est l'interface de base du logiciel au jourd'hui, qu'ils apprennent avec et aurons eux aussi du mal à s'en passer comme les "anciens" on du mal à se passer de l'inteface plus classique. Ce qui est dommage c'es de voir l'utilisation de la ligne de commande disparaitre, personnelelment j'y trouve un gain de temps non négligeable et des possibilités plus étendues.

Bonjour, le XEON W3503 n'est pas Hypertreadé. Donc tu aura 2 cœurs et donc 2 gestion de cœurs dans le gestionnaire de taches si tu n'a qu'UN processeur, et 4 si tu en à deux. En sachant qu'Autocad ne gère pas le multiprocesseur (même pour le rendu) et pas le multicoeur au dessus de 4 cœurs (à vérifier toutefois), ça tombe bien! (ou pas si tu veu faire d'autres taches en parallèle). Selon moi ce processeur est largement suffisant pour de la 2D/3D légère sur les dernier Autocad, un i5/i7 donneront de bien meilleurs résultat avec leurs 4 cœurs (x2 en HT sur le i7) et leur technologie plus avancé. Ensuite au niveau de la RAM je resterais sur mes reserves car je n'ai pas pus tester en profondeur les Autocad au dessus du 2011 mais il m'est apparus à de nombreuses reprises l'impossibilité de dépasser une valeur max sans plantage (1 à 3 Go environs et ceci même en OS 64bits). Dans tous les cas, plus de Ram ne fait jamais de mal et dans le cas ou il y ait plusieurs logiciels qui travaillent en même temps 8Go me semblent également le minimum et 16 commencent à être confortable. Tu peu très bien faire du multi-écrans sur une seule et même carte graphique, si elle est pourvue de plusieurs sorties. Généralement une CG classique est limité à deux écrans, mais avec les dernières technologies l'on peu monter à 6 écrans par carte. Pour finir, aujourd'hui le facteur le plus générateur de lenteur sur un poste informatique est son disque dur. Je conseillerais donc grandement de passer à un SSD, le gain est réellement non négligeable, surtout sur les SSD haut de gamme. Mais dans tous les cas un SSD ne comblera pas les lenteurs d'un réseau ou est disposé le plan (si tel est ton cas), il apportera uniquement un lancement d'applications très rapide et limitera tous les temps de chargement d'Autocad. En espérant avoir pus aider.

Bonjour, Pense à la souscription Autodesk, si je me troupe pas tu est moins cher qu'une version tous les 3 ans! (et tu aura des bonus en plus). @+

Bonjour, Pour moi la seule solution conciste à faire un LISP qui créerais sur un calque spécifique le même point mais avec l'arrondis de la précision. Ce qui permettrais d'avoir un calque qui servirais pour l'accrochage lors du travail et un autre qui lui serait l'origine de l'info et donc conforme à ce qui est livré par l'archi. Mais j'ai du mal à voir l'intérêt de la chose. :blink: @+

Exactement! Et je n'en veu a personne d'aider à clarifier mes propos ;) POur ifo c'est généralisable si les cercle sont sur un calque spécifique. il suffit de faire un cadre (rectangle ou polyligne fermé) autours des cercle que l'on souhaite passer en polyligne et de faire un CONTOUR (ou CN) en sélectionnant la zonne et non un cercle. Ne reste ensuite qu'a supprimer la zone et le contour crée. @+ ps: tout ceci crée bien sur un double de l'élément d'origine qui est le cercle, il ne le transforme pas réelement.

Ou un simple contour avec CN. ;)

Bonjour, Première méthode simple : - Import en FDO du SHP. - Puis clic droit sur la couche et Export en SQLITE. ou sinon : - Import en MAP (et non FDO) du SHP - Attribution des tables et des champs dans l'import - Export en SQLITE avec MAP - Attribution des tables et des champs dans l'export Et pour le passage SQLITE -> SHP c'est la seconde méthode en sens inverse qui fonctionne. Tout ceci ne fonctionnant que si toutes les entrées de la table ont une géométrie (les géométries perdues le resterons à jamais). J'espére avoir répondu à la question. @+

Bonjour, j'aurai tendance à dire que c'est le moment d'expliquer au service info le besoin et "d'imposer" cette installation de TrueView (qui est gratuit, fournis par Autodesk ety peu servir à se prémunir de l'installation de nombre de poste Autocad utiliser en visionneurs de plans tout en permettant la convertion rapide et sur des plans d'un format à un autre). @+

bonjour, Pour sélectionner à l'écran un sssetfirst sera necessaire : (sssetfirst nil ssnum) A mettre après la commande de sélection bien sur. Sinon un sslength te donnera le nombre d'élément dans la sélection, et donc si ta sélection est vide ou non! @+

Bonjour, A voir si la décomposition des object AEC de TrueView (dans la fonction de conversion) peu régler ce soucis. @+

Idem, même si mon expérience des ces langages et de la doc en est faible, il y a quelques lacunes qu'il serait interressant de combler (une seule Doc ou un seul et meêm endroit pour toutes les docs serait déjà un gros plus).

Bonjour, Dans ce cas pas de CTRL+A sinon tu sélectionne tous les objets de tous les calques même les innactif! @+

Bonjour, Le truc (comme dit par vincentp010 ) c'est que je passe en revu tous les objets des blocs. Dans le cas d'un point d'alti classique ça fait juste 3 élément (point + 2 atributs), donc si en plus il n'y a pas de filtres de blocs et que tu a des blocs lourd ça devient TRES LONG! Le Vlist fournis par vincentp010 résoud se problème de vitesse en se concentrant sur les attributs et en passant par du Vlisp. Il tes reste plus qu'a lancer la routine et à prendre la pause dej' ;) @+

Bonjour, Après quelques jours de tests divers et variés, d'exploitation des tables sous différents formats et de tests de ces formats en dehors d'autocad. Mon choix s'est porté sur l'utilisation de table en SQLITE. Mes raisons : - c'est aussi simple à utiliser sous Autocad MAP - c'est plus rapide dans de nombreux cas que le SHP, et semble plus rapide que le SDF (à vérifier) - c'est contenu dans un seul et unique fichier de taille relativement correcte - ça me permet d'éditer les table dans un logiciel externe (SQLiteStudio emporte ma préférence pour mon utilisation) et donc d'éditer l'ordre des tables, leurs nom, leurs champs, de les indexer, ... - pour le moment l'édition de mes tables sous un logiciel externe est pris en compte sans aucune erreurs lors du réimport sous Autocad via FDO. Si vous chercher donc à réorganiser vos table il semble donc "simple" de passer par le SQLITe puis de réexporter en SHP/SDF ensuite (si besoin). Merci a vous tous pour votre aide et vos conseils.

Un lisp moche et long à traiter qui fait ce que tu a besoin (normalement): (defun c:monattrib ( / Monbloc MonCalqueAttrib ss i MaSelec) (setq ss (ssget "_X" '((0 . "INSERT")))) (setq MonCalqueAttrib (getstring "Sur quel calque? ")) (setq i 0) (setq MaSelec (ssadd)) (while (setq MonBloc (ssname ss i)) (setq i (1+ i)) (while Monbloc (if (and (eq "ATTRIB" (cdr (assoc 0 (entget Monbloc)))) (eq MonCalqueAttrib (cdr(assoc 8 (entget Monbloc))))) (ssadd (cdr (assoc 330 (entget Monbloc))) MaSelec) ) (setq Monbloc (entnext Monbloc)) ) ) (setq SelectionEnCours MaSelec) (sssetfirst nil MaSelec) ) Si tu a un seul bloc qui est concerné tu peu ajouter à : (setq ss (ssget "_X" '((0 . "INSERT")))) Donc : (setq ss (ssget "_X" '((0 . "INSERT")(2 . "Le_Nom_De_Mon_Bloc")))) Sachant que les carractéres génériques sont pris en compte. Pour exemple, pour tous les bloc TCPOINT avec une numérotation (TCPOINT_1,TCPOINT_2,...) que certains logiciels peuvent produire,tu pourra écrire "TCPOINT*" comme nom de bloc. Ceci accélérera grandement le traitement si tu a de nombreux blocs qui ne sont pas concernés. En espérant que ça réponde au besoin.

Bonjour, Tu peu appliquer ceci : - Sélection du calque "toto" comme calque courrant. - Gel de tous les calques sauf "toto". - Sélection de tous les objets automatiquement (CTRL+A), ou en manuel à la souris. Il faut bien penser à geler les calques et pas uniquement les désactiver. En espérant que ça réponde à ton besoin. @+

Bonjour, la macro -calque E "nomdemoncalque" Rend courrant le calque désiré ou le crée si il n'existe pas! @+

Outch effectivement je n'avais pas bien lu le provblème énnoncé. Donc j'ai tout faux, et le "eval" est la solution. Intéressant ce "read", couplé à un "set" et "eval" on definit autant de variables que necessaire. J'me coucherais encore moin bête tien! @+

Bonjour, Pour lire la valeur d'une variable tu peu faire un simple (princ mavar) Et dans ton cas un simple (strcat ...) renvoie la valeur concatené des chaines de caractére qui suivent. Ici (read(strcat "hand" ntxt)) ne sera jamais égal à "0", donc tu ne passera jamais à la suite. En effet tu concaténe "hand" à ta variable ntxt, donc quelque soit la valeure de celle-ci tu aura toujours le préfixe "hand". Donc tu peu tester de cette manière : (if (eq (strcat "hand" ntxt) "hand0" ) (...) )

J'ai testé du SQL toute la journée. Le résultat est bien plus rapide à l'usage, le chargement de la table est quasi imédia par rapport au SHP. Pour le moment la stabilité à l'air meilleure dans mon cas. Il faut dire que j'ai également revu un peu ma procédure d'enregistrement des mes données. Précédement j'avais fait un bouton qui lançait l'enregistrement des tous les objets extrais des tables, puis immédiatement un degel de tous les calques (car j'associe des plans d'equels j'extrais les données que j'enregistre dans ma table), plus suppression de tous les objets (la couche FDO étant bien sur en non sélectionnable). La résultat était hasardeux (si c'est bien ça qui n'allait pas) bien que rapide et efficace dans un grand nombre de cas! Pour le moment je suis le seul à travailler sur cette couche, et heureusement, je crains le pire quand elle devra être partagé. Il y avait l'idée d'accéder à cette couche via une base SDE, j'ai peur que nous ne devions passer par d'autre méthodes vu les bug très aléatoirement rencontrés lors des test. Merci pour ton aide et tes conseils, et bonnes vacances!