Aller au contenu

Messages recommandés

Posté(e)

Ayant réglé mon problème avec les blocs dynamiques dans le précédent sujet, je suis confronté à un nouveau problème.

 

J'ai un bloc dynamique avec deux paramètres : un étirement polaire et un état de visibilité.

 

En fait j'aimerai que l'état de visibilité dépende de la valeur de l'étirement (de l'angle pour être précis).

 

Donc j'ai crée un réacteur sur l'évènement :

(:vlr-objectClosed . bloc_update)

 

La fonction bloc_update est donc déclenchée quand je relâche la poignée d'étirement.

 

jusque la ça marche

 

Le problème c'est que j'aimerai que dans la fonction bloc_update un état de visibilité du bloc soit modifié.

 

J'essaye de coder le truc : PAF ! erreur fatale pour cause de boucle infinie.

 

(indépendamment du réacteur la routine d'état de visibilité marche)

 

J'ai essayer de désactiver le réacteur avec

(vlr-remove-all)

 

Mais non seulement ça plante encore mais en plus le réacteur est toujours actif...

 

Qu'ai je oublié ?

 

Merci d'avance !

 

[Edité le 5/11/2008 par pingoo666]

Posté(e)

Salut

 

Surtout pas de (vlr-remove-all), car avec cette fonction tu supprimes de la mémoire tous les réacteurs du dessin courant.

 

L'idéal est d'utiliser un (vlr-remove variable_de_mon_reacteur).

 

mais en plus le réacteur est toujours actif...

Pas après un (vlr-remove-all), mais peut-être la variable qui n'a pas été remise à zéro

 

Un bout de code pour lister les réacteurs

(defun c:lstrea(/ eve rea)
 (foreach rea (vlr-reactors)
   (foreach eve (cdr rea)
     (princ "\nFamille du réacteur ")
     (princ (car rea))
     (princ "\nEvènement : ")
     (princ (vlr-reactions eve))
   )
 )
 (princ)
)

 

@+

Les Lisps de Patrick

Le but n'est pas toujours placé pour être atteint, mais pour servir de point de mire.

Joseph Joubert, 1754-1824

Posté(e)

Salut,

 

C'est normal que ca boucle ;) , j'étais tombé sur le même problème, et la solution est super simple :) :

en fait que tu changes ton étirement polaire, ton réacteur se lance, la dedans tu appels

une màj de la propriété de visibilité, et donc celle-ci rappelle à nouveau ton réacteur (normal).

En fait dans ta fonction appelée dans le réacteur, test si ton paramètre de visibilité est à la bonne

valeur, si oui, c'est que tu la changés et donc ce n'est plus nécessaire de le changer.

ainsi tu stoppes la boucle.

Élémentaire mon cher :cool:

Tous pour lisp, Lisp pour tous!

Avec Revit, cela ne vas trop vite...

Posté(e)

Salut,

 

Une méthode consisterait avoir une réacteur :vlr-object-openedForModify sur les objets que tu surveilles dont la fonction callback construirait un nouveau récteur :vlr-commandEnded.

La fonction callback de ce réacteur détruit le premier réacteur, fait les modifications, le reconstruit et détruit le second.

 

;; Construction du premier réacteur (object)
(or *reactor1*
   (setq *reactor1* (vlr-object-reactor
	     *obj-lst*
	     nil
	     '((:vlr-openedForModify . callback1))
	   )
   )
)

;; callback1 du premier réacteur
(defun callback1 (own rea lst)

 ;; destruction du second réacteur s'il existait déjà
 (and *reactor2* (vlr-remove *reactor2*))

 ;; construction du second réacteur
 (setq	*reactor2* (vlr-command-reactor
	    own
	    '((:vlr-commandEnded . callback2))
	  )
 )
)

;; callback du second réacteur
(defun callback2 (rea cmd)

 (if (= (car cmd) "GRIP_STRETCH")
   (progn

     ;; destruction du premier réacteur
     (vlr-remove *reactor1*) 

     ;; modification de l'objet qu a été étiré (à remplacer par ce que tu veux)
     (vla-put-Color (vlr-data *reactor2*) 1)

     ;; reconstruction du premier réacteur
     (setq *reactor1*
     (vlr-object-reactor
       *obj-lst*
       nil
       '((:vlr-openedForModify . callback1))
     )
     )
   )
 )

 ;; destruction du premier réacteur
 (and *reactor2*
      (vlr-remove *reactor2*)
      (setq *reactor2* nil)
 )
) 

Gilles Chanteau - gileCAD - GitHub
Développements sur mesure pour AutoCAD

Posté(e)
Salut

 

Surtout pas de (vlr-remove-all), car avec cette fonction tu supprimes de la mémoire tous les réacteurs du dessin courant.

 

L'idéal est d'utiliser un (vlr-remove variable_de_mon_reacteur).

 

mais en plus le réacteur est toujours actif...

Pas après un (vlr-remove-all), mais peut-être la variable qui n'a pas été remise à zéro

 

Un bout de code pour lister les réacteurs

(defun c:lstrea(/ eve rea)
 (foreach rea (vlr-reactors)
   (foreach eve (cdr rea)
     (princ "\nFamille du réacteur ")
     (princ (car rea))
     (princ "\nEvènement : ")
     (princ (vlr-reactions eve))
   )
 )
 (princ)
)

 

@+

 

Je suis d'accord que normalement le vlr-remove-all "tue" tous les réacteurs mais la ca ne marche pas.

 

j'ai aucun réacteur actif d'après la commande (vlr-reactors) mais ça marche quand même...

Posté(e)

Bonjour

 

j'ai aucun réacteur actif d'après la commande (vlr-reactors) mais ça marche quand même...

A moins que tu ais un/des réacteur(s) permanent(s).

 

un (vlr-pers-list), indication te donneras.

 

j'aime beaucoup l'usage que tu fait de (and) c'est très élégant.

Le (or) aussi tu as.

 

@+

Les Lisps de Patrick

Le but n'est pas toujours placé pour être atteint, mais pour servir de point de mire.

Joseph Joubert, 1754-1824

Posté(e)

Non ils ne sont pas persistants, j'y ai déjà pensé.

 

En fait j'ai l'impression que quand on essaye de "tuer" un réacteur dans la fonction qu'il appelle ça ne marche pas.

 

(vlr-remove-all) semble fonctionner, car si après je fais (vlr-reactors) ca me renvoie nil.

 

Par contre le réacteur fonctionne toujours...

 

Et si je fais (vlr-remove-all) en dehors du callback là c'est bon le réacteur est bien désactivé.

 

A croire qu'il reste en mémoire mais qu'il n'est plus dans la base...

 

 

 

 

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer. Politique de confidentialité