I’m using Clockwork’s node Element.OwnerView to get the views that revision clouds appear in. It works great, except I get the primary views, rather than the sheeted dependent view where the cloud is visible. How can I find out which dependent view the cloud is visible in?
I’m trying to create a script that lists revision clouds, their comments and the sheets they appear on - I have an older one that primarily relies on borrowed python, and while it works it is really slow and becomes unusable on large projects.
Hmm could you show a screenshot or elaborate more on how you are collecting the revision clouds that you are passing through the Element.OwnerView node? Hard to tell without seeing what you are currently working with, but maybe the “Elements in view by category” node from the MEPover package could help…
Note the List.Flatten node’s sublists 0 and 1 both have a Revision Cloud with the same Element ID - this is because the second view is a dependent of the first view
Archi-lab also has a few nodes - Sheet.Revisions will list all revisions on a sheet and RevisionCloud.Revision will get the revision instance from a revision cloud. You could use these to compare all Revision Clouds in the project to the Revisions on sheets.
Below is an image of what I was trying for: Getting all the revisions on the sheet, and then finding where the host views are. I was looking for a way to loop any primary views through some nodes that would identify the dependent views where the revision cloud is available.
It looks like the MEPover node could work if I pair it with other code to get the revisions directly on the sheet (and use the Springs.Sheet.Views+ node to get the views, since I have area plans on a sheet that cause the default node to fail) but I’d prefer to just run it on the dependent views of the identified host, so I’ll have to see if I can identify those views.
Sheet.Revisions just identifies the revisions a sheet has had. I don’t need the older revisions, and can get the current ones with a Revit schedule. RevisionCloud.Revision doesn’t solve the problem of identifying the location of the revision clouds.
This got me curious of how to find the dependent views with the API, so I ended up quickly writing this python script out and I think it is achieving what you’re aiming for:
import clr
clr.AddReference('RevitAPI')
from Autodesk.Revit.DB import*
clr.AddReference('RevitServices')
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager
doc = DocumentManager.Instance.CurrentDBDocument
views = UnwrapElement(IN[0])
dependents = []
for view in views:
els = []
ids = view.GetDependentViewIds()
for id in ids:
els.append(doc.GetElement(id))
dependents.append(els)
OUT = dependents
I was about to edit to add, however, that the list structure is lost in the Python script so some added work after the python script would need to be done to associate the Revision Clouds to the views… I think you’d have a better idea on how to fix that within the Python code. I noticed the list structure remains if I exclude the doc.GetElement part, but then there would need to be an “Element from ID” node afterwards
Ah thank you @Nick_Boyts that makes sense now that I see it I edited my post with the code so it works with the initial list structure now
@jacob.small sorry to answer your question for the original post-er, but I got curious myself as well;
querying the revision cloud’s Workset only returns the primary views the same way that the Element.OwnerView node does… in retrospect, it makes sense, because it is a single element that is not duplicated or changed when it appears in dependent views, so I’d think it would need additional parameters to house information related to any dependent views it appears in
Thank you both for your help! @jacob.small I originally tried the workset route - the problem I was running into was that I could get a name, but not the view element, so I couldn’t get other data from it.
I ended up creating two different versions, which I’ll split and try on a more complex project to see if there is a time difference. Both use MEPover and Springs packages, the second also uses Clockwork.
The first uses less nodes and doesn’t require the python script, but only works for the current revision. This is normally all that’s needed, so should be sufficient for most applications. It gets the sheets and then the revisions.
The second has more nodes. It was based of my origina workflow of getting the revision clouds an then the sheets, but ended up being harder to code. A large code block is dedicated to getting the right sheet for revision clouds in dependent views, and was more clumsy to sort the sheets after identifying comments. The benefit of this script is that it is possible to get data for a revision that is not current.
Well the second script, getting the revision clouds first and working backwards, definitely runs faster (on a large projects it was 2 minutes, while the other one is at 10 minutes & still going). The data was right on the project I used to build it, but on this larger project there are errors, some nulls get in, so I’ll have to track down what is causing that.
This might be something for a different post but somewhat similar. When you cull the cloud from a Legend view how do you find what sheets it has been placed?
Any way you can post a pic with a higher detail to read the node titles or the script itself? I have a 3rd party tool that can export/report the data for revision info, but the script has utility for other situations. Thank you.
This is the script as it stands now. It works great in Dynamo 1.3, but if I try to open it in Dynamo 2.0 it crashes both dynamo and Revit, so I’ll need to see about recreating it from the image myself
Hopefully this is readable - I had to scale it down to meet the forum requirements.
Sweet. Just one last request. What’s the Python Script found in the group “Find dependent views from the primary & replace them in the list”? Is it the stuff @awilliams & @Nick_Boyts posted?
I edited my post with the code so it works with the initial list structure now
