2016-11-21 1 views
0

Actuellement, j'ai créé un outil pour renommer les numéros de vue ("Numéro de détail") sur une feuille en fonction de leur emplacement sur la feuille. Là où cela casse, ce sont les transactions. Im essayant de faire deux transactions séquentiellement dans Revit Python Shell. J'ai aussi fait cela à l'origine en dynamo, et cela a eu un échec similaire, donc je sais que c'est quelque chose à voir avec les transactions.2 Transactions séquentielles, réglage Numéro de détail (Revit API/Python)

Transaction # 1: Ajouter un suffixe (« -x ») à chaque numéro de détail pour assurer que les nouveaux numéros seront pas en conflit (1 sera 1-x, 4 sera 4-x, etc.)

Transaction # 2: numéros de changement de détail avec le nouveau nombre calculé en fonction de l'emplacement de la fenêtre (1-x sera 3, 4-x sera 2, etc.)

meilleure explication visuelle ici: https://www.docdroid.net/EP1K9Di/161115-viewport-diagram-.pdf.html fichier Py ici: http://pastebin.com/7PyWA0gV

Ci-joint le fichier python, mais essentiellement ce que Im essayant de faire est:

  # <---- Make unique numbers  
      t = Transaction(doc, 'Rename Detail Numbers') 
      t.Start() 
      for i, viewport in enumerate(viewports): 
          setParam(viewport, "Detail Number",getParam(viewport,"Detail Number")+"x") 
      t.Commit() 

      # <---- Do the thang   
      t2 = Transaction(doc, 'Rename Detail Numbers') 
      t2.Start() 
      for i, viewport in enumerate(viewports): 
          setParam(viewport, "Detail Number",detailViewNumberData[i]) 
      t2.Commit() 

Ci-joint py

+0

Ce qui est exactement défaut? La première boucle de transactions fonctionne-t-elle correctement? – 0w3n

Répondre

0

Donc, cette question avait en fait rien à voir avec les opérations ou la régénération doc. J'ai découvert (avec un peu d'aide :)), que le problème a menti dans la façon dont je mettais/obtenant le paramètre. "Nombre de détails", comme beaucoup de paramètres, a des versions en double qui partagent le même nom de paramètre descriptif dans un élément de fenêtre.

Apparemment, la raison en est peut-être des problèmes hérités, mais je ne suis pas sûr. Ainsi, lorsque j'essayais d'obtenir/définir un numéro de détail, il saisissait de temps en temps le mauvais paramètre en lecture seule, appelé "VIEWER _DETAIL_NUMBER" en tant qu'énumération intégrée. La bonne est appelée "VIEWPORT _DETAIL_NUMBER". Cela arrivait parce que j'essayais d'obtenir le param juste en passant le nom de paramètre descriptif "Numéro de détail" .Revising comment je obtenir/définir des paramètres via builtIn enum résolu ce problème. Voir les images ci-dessous.

S'il vous plaît voir pdf pour explication visuelle: https://www.docdroid.net/WbAHBGj/161206-detail-number.pdf.html

+0

merci de partager la solution finale. J'ai nettoyé et publié ce fil sur The Building Coder: http://thebuildingcoder.typepad.com/blog/2016/12/need-for-regen-and-parameter-display-name-confusion.html –

2

Comme je l'ai expliqué dans ma réponse à your comment in the Revit API discussion forum, le comportement que vous décrivez pourrait bien être causée par un besoin de régénérer entre les transactions. La première modification fait quelque chose, et le modèle doit être régénéré avant que les modifications prennent tout leur effet et se reflètent dans les valeurs des paramètres que vous interrogez dans la deuxième transaction. Vous accédez à des données périmées. Le Building Coder fournit tous les détails Nitty Gritty et de nombreux exemples sur le need to regenerate.

Résumé de ce fil de discussion, y compris les problèmes abordés:

http://thebuildingcoder.typepad.com/blog/2016/12/need-for-regen-and-parameter-display-name-confusion.html