I am trying to grab the Viewports located on a linked Sheet. I have tried View.GetViewport (SteamNodes) and Sheet.GetViewportsAndViews (Rhythm). They both grab the Viewports of two sheets and then return null for the rest. View.GetViewport returns null for each viewport placed on the sheet and I have confirmed the sheets are not blank. Does anyone have any ideas?
Sheet.GetViewportsAndViews warning:
Warning: Sheet.GetViewportsAndViews operation failed.
The call is ambiguous between the following methods or properties: ‘Revit.Elements.ElementWrapper.Wrap(Autodesk.Revit.DB.CurtainSystem, bool)’ and ‘Revit.Elements.ElementWrapper.Wrap(Autodesk.Revit.DB.FamilyInstance, bool)’
Speaking for my node, it was not made to work with linked documents. That would require an additional input unfortunately. For it to be working with two sheets is odd to me, (if they are in the link).
The error you are receiving on the node is a random one that happens when nulls occur. In the case of selecting viewports I am trying to do that in the current document on my node and this is most likely the cause. For now, I imagine you could dissect steamnodes’ node and add an additional input for document. I can try to add this functionality to my node in a future update as well.
Thanks for the reply. I did not think the nodes would work when I plunged them in but I like trying. The results are strange since they do work on two of the sheets. I have confirmed that the two sheets are from a linked file. This is how I am grabbing the sheets (No other sheets are being collected in this graph).
Could it be that the linked sheets shares the same GUID as a sheet in the current file? Both files were created from the same template. (Its an old temple so I would have to dig up the archive to check).
I have already built a workaround by collect all linked views, get the sheet they are placed on and finally match the two lists.
The node is working great. Thank you for making the change so quickly, it really helped clean up my graph. I have not noticed any problems with it yet.
Thank you @john_pierson! I wanted to share with you the node error I was getting, along with the package upgrade warning, to see what problems I could possibly find myself dealing with by upgrading the Rhythm package.
The upgrade warning can be ignored. It’s because I published from Revit 2020 and dynamo 2.3.0. Since they are both 2.x versions it is ignorable.
The other warning is because the node couldn’t return some of the elements. Like I said, expanding linked elements into memory is quite messy.
To elaborate a bit more on that:
Dynamo was/is made to work on the current Document primarily. This is why things like setting parameters, getting active views, etc. only ever works on your current file. Even though this is a restriction of Dynamo, we have limited access to Revit’s background workflows for Documents. This means we can do some things like collect elements and whatnot. But, we sometimes run into problems when Dynamo tries to return the elements as an output. That is what that error means. It got confused and does not know what to do.
As you can see, @Steven ran into the same thing previously.
I greatly appreciate the dialog here! I will for sure update the package and let you know what the results are.
Might using the Document.Open and Document.Close nodes lessen this confusion at all when trying to perform tasks such as this? As I’ve not used these two nodes before, I guess I’m just more curious as to what their purpose is when information from linked documents can still be queried without actually “opening” them in the background.
Those nodes are for files that are not links. I have primarily seen them used for when people want to bring in something wall types from a resource library.
Let me push it to the package manager now for you to test out!
or viewports if you can extract viewport name and detail number