question de structure (CopyObjects)

[krunch]

Bonjour

 

Pour une commande Lisp je suis en train d'adopter une structure particulière, et je voudrais savoir si elle est acceptable ou pas...

La particularité c'est qu'elle restituerait une copie des entités sélectionnées tout en supprimerait la sélection initiale.

 

Selon vous faut-il abandonner cette solution ?

 

Questions subsidiaires :

- Le problème c'est sans doute les données associées éventuelles : XDatas, Réacteurs objets... y en a t-il d'autres ?

- Est ce que la fonction CopyObjects se charge de copier ces données associées ?

- A quoi sert l'argument IdPairs ??

- En dehors de ce problème y a t'il un inconvénient à ce que le handle des entités soit modifié ?

 

Merci d'avance

 

[Edité le 19/1/2011 par krunch]

[Bred]

Salut,

 

qu'elle restituerait une copie des entités sélectionnées tout en supprimerait la sélection initiale.

 

Tu veux donc faire un déplacer mais en changeant le handle de ton entité ?

 

En autolisp, commande copier puis effacer.

 

en vl : vla-copy puis vla-delete.

 

 

[Edité le 20/1/2011 par Bred]

[krunch]

Oui, mais c'est pas que " je veux"..

En fait c'est une conséquence de la structure que je voudrais adopter, qui présente un gros avantage : la rapidité d'exécution.

 

Mais c'est une conséquence plutôt gênante (données associées aux entités)...

 

Ma double question était donc :

- est ce que selon vous c'est acceptable ou pas ?

- est ce qu'il y a un moyen d'y remédier ?

[Bred]

Re,

j'avoue ne pas comprendre ta question alors....

 

Que cherches-tu a faire exactement ?

 

(PS : nous sommes bien d'accord que tu es dans le forum lisp ?)

[(gile)]

Ta demande est assez peu compréhensible

 

Autant la commande native COPIER (_COPY) que la fonction LISP vla-copy copie les objets et les données qui sont attachées à l'objet (xdata, dictionnaire d'extension).

vla-copy-objects fait du 'deep-cloning' et n'est utile que pour copier d'un espace à un autre ou d'un fichier à un autre.

[krunch]

(PS : nous sommes bien d'accord que tu es dans le forum lisp ?)

Oui, on est d'accord :-)

 

Bon je reformule...

 

Imaginez une commande usuelle comme _Move par exemple (mais en mieux), qui à chaque utilisation restitue une copie de la sélection initiale (vous vous en rendez compte parce que le handle des entités a changé) : elle a donc copié, déplacé et effacé la sélection...

Évidemment ce n'est pas ce qu'on lui demande, même si dans la majorité des cas ce n'est pas très gênant. Mais le fait qu'elle copie est une conséquence de sa structure, c'est comme ça !

 

Ma question est : est ce que vous gardez quand même cette commande ou est ce que selon vous c'est rédhibitoire ?

 

Il me semble que l'inconvénient vient surtout d'éventuelles données associées (XDatas, réacteurs), et comme elle utilise (CopyObjects) je voulais savoir si il y avait un moyen de garder les données associées.

Je me demandais aussi si il y avait d'autres raisons qui feraient que cette particularité est gênante..

 

Voilà, en espérant être plus clair, merci d'avoir répondu..

[krunch]

Ok merci gile, donc il vaudrait mieux utiliser vla-copy..

 

Je vais regarder ça, mais pour être plus précis la séquence complète est :

copie dans un nouveau bloc > insertion > traitement > explode

D'où l'utilisation de (CopyObjects)..

 

L'avantage est un temps de traitement incomparablement plus rapide qu'une itération dans un jeu de sélection (avec des énormes sélections bien sûr) : plusieurs centaines de fois plus rapides.. et même, bizarrement, plus rapide qu'avec la commande _Move tout en restant en Lisp !!

 

PS: c'est la raison pour laquelle je posais cette question là : http://www.cadxp.com/sujetXForum-31240.htm

 

[Edité le 20/1/2011 par krunch]

[(gile)]

En complément de ce que j'ai dit plus haut, CopyObjects copie aussi les données attachées.

 

En ce qui concerne les réacteurs d'objets (j'imagine qu'il s'agit de réacteurs LISP), ils ne seront pas copiés à moins que l'application qui a créé ces réacteurs ne l'aie prévu (c'est ce que j'avais fait avec le LISP Rectangle)

[krunch]

D'accord, donc je peux garder (CopyObjects)..

 

j'imagine qu'il s'agit de réacteurs LISP

Justement j'en sais rien : le but est de faire une commande usuelle, utilisable dans tous les cas de figure.

 

Cette astuce (traitement d'une RefBloc plutôt que d'un jeu de sélection) vaut vraiment le coup d'être exploité..

 

Alors ma question était générale : finalement est ce que c'est si gênant que ça ?

[(gile)]

Excuse moi moi mais ta demande est toujours aussi incompréhensible.

 

Pourquoi utilise-tu CopyObjects ?

Je répète, le deep cloning n'est utile qu'entre des espaces (BlockTableRecords) différents, est-ce bien le cas ?

Sinon, je ne vois vraiment pas l'intérêt.

[krunch]

J'utilise (CopyObjects) pour fabriquer une référence de bloc (donc un bloc) à partir de la sélection. Il me semble qu'il n'y a pas d'alternative pour ça ?

[(gile)]

Effectivement, si c'est pour créer un bloc c'est la solution, mais dans ce cas, je ne comprends pas tes inquiétudes concernant les données attachées et encore moins les réacteurs puisque les entités composant une référence de bloc ne sont pas accessibles comme le sont les entités de premier niveau.

 

Si c'est, comme il m'avais semblé et comme semble l'avoir compris Bred, pour faire un déplacer dans le même espace, je trouve ça très tordu. De plus le fait de copier (quelque soit la méthode) des entités changera le handle de ces entités et là, les éventuels liens avec d'autres entités via des réacteurs seraient perdus.

[krunch]

puisque les entités composant une référence de bloc ne sont pas accessibles comme le sont les entités de premier niveau

A la fin la RefBloc est explosée, donc les entités se retrouvent à leur niveau initial

 

je trouve ça très tordu

Effectivement c'est tordu, mais l'avantage est que je me retrouve avec une commande Lisp plus rapide qu'une commande standard (tu peux essayer c'est impressionnant)

Alors qu'avec une itération du jeu de sélection j'ai largement le temps de me faire un café.. (je la teste avec des sélections de 10 à 20 000 objets)

 

C'est bien pour ça que je vous demandais si c'est acceptable ou pas..

 

 

Je rectifie : le explode prend un peu de temps, mais l'affichage de la preview (avant explode) est bien + rapide

Par ailleurs ce n'est bien sûr pas pour faire une simple _Move, c'est pour faire un outils de transformations paramétrables, une sorte de "_MoveRotateScaleMirror"...

 

[Edité le 20/1/2011 par krunch]

[Bred]

Re,

Si j'ai bien tout suivi, ton but est donc de faire un déplacer, mais comme tu dois traiter un très grand nombre d'objet, tu passe par la création de bloc constitué de toute tes entités que tu déplace puis explose ?

 

Si c'est cela, je pense que tu fais en partie fausse route : ce qui ralenti le déplacement d'un objet est je pense en premier lieu l'affichage.

Je n'ai pas essayer, mais pour passer outre l'affichage, l'un des moyens est de ne plus afficher tes objets à l'écran au moment du déplacement et du "raffichage".

Voir de travailler sur ton fichier sans l'ouvrir grâce aux fonctions ObjectDbx (http://www.cadxp.com/sujetXForum-13402.htm)

 

[krunch]

Re-salut

 

Si j'ai bien tout suivi, ton but est donc de faire un déplacer, mais comme tu dois traiter un très grand nombre d'objet, tu passe par la création de bloc constitué de toute tes entités que tu déplace puis explose ?

C'est tout à fait ça, sauf que ce n'est pas un Move mais un Transformby, et c'est même des Transformby successifs sur une même sélection.

 

pour passer outre l'affichage...

Au contraire c'est justement ce que je cherche à accélérer, je ne veux surtout pas passer outre...

 

Bref, la solution est sans doute un peu trop tordue...

 

 

L'autre piste est la question que j'ai posée ici : http://www.cadxp.com/sujetXForum-31240.htm (comment passer une matrice à une routine vba)

Si quelqu'un a une idée là dessus....

 

 

En attendant merci pour vos réponses