Find dependent view where element is visible

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

1 Like

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.

Ah never mind. I thought RevisionCloud.Revision was getting an instance of that revision.

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
from Autodesk.Revit.DB import*

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:

OUT = dependents

Dangit, Amy. I was just about to post this. :smile:

Hah @Nick_Boyts ! I had to try it for myself!! :rofl:

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 :thinking:

Out of curiosity, what happens if you get the workset from the revision cloud itself?

You need one more nested list.

for view in views:
	els = []
	ids = view.GetDependentViewIds()
	for id in ids:
OUT = dependents

Ah thank you @Nick_Boyts that makes sense now that I see it :sweat_smile: I edited my post with the code so it works with the initial list structure now

@JacobSmall 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!
@JacobSmall 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.

1 Like

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.

1 Like

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?

Yes, its their scripts

Hi awilliams,

I followed exact same steps but I got a dereferencing a non pointer error. What would you suggest me to do? Thank you

That’s because of your Empty Lists. You’d have to clean those up and likely remove their respective parent views as well.