Document.CopyFromViewToView

Revit
1

I am trying to use the Document.CopyFromViewToView node, and it is giving me all null values. My source view is an independent view, and it seems like a lacing issue, but I am not sure why.

image
image585×832 127 KB

2

That list you’re inputting into ‘destView’ doesn’t appear to be a list of views, it looks like a list of view names maybe? Try inputting the actual view elements like you have with your ‘sourceView’ list.

1 Like
3

What Package is the Document.CopyFromViewToView node from?

4

Springs

1 Like
5

I have a similar problem with coping tags between views. Do you have any idea what is wrong?
Springs Node 210.1.1

image
image1281×708 153 KB

6

Hi, I think I also had an issue with copying tags by this node.

I eneded up re-creating tags by host element and location with Genious Loci Create Tag node.

7

Thanks for the tip! I can indeed create new tags using the location and data in the source view.

However…

During my internal investigation yesterday, I discovered something interesting: tags appear to be linked to specific views.

For example, the identical TAG_1(family name/type, data) exists in two independent views: VIEW_1 and VIEW_2.

When I attempt to copy TAG_1 from VIEW_1 (source view) to a new view, VIEW_1_NEW (destination view), I find that this tag is somehow connected to VIEW_2. When I click on the specific ID in Dynamo, it directs me to VIEW_2 instead of the intended VIEW_1 (source view) that I specified for copying.

This leads me to conclude that the script (component) isn’t functioning properly because it seems to be referencing TAG_1 in VIEW_1 (source view), which it claims doesn’t exist there, despite both views having identical TAG_1s.

This behavior is quite puzzling, and I’m currently struggling to find a suitable solution. I’m not sure if the tags are interconnected in some way—for instance, could it be that when I create a new tag in a view, it gets assigned as the “source” tag? It’s a mystery.

8

Double check the element ID of the tag in each view and the views themselves. I recall that dependent views add a lot of shenanigans which are not initially exposed to end users.

As another test you can try with a view which doesn’t have dependents involved, if that works then you reduced the scope to your model or the feature - so you can then test a sample mode started from the ‘’ template to recreate the dependent views situation to see if that fixes it. If so, it is something else in your model (no idea what). If not then it is a dependent view issue and posting that model might help.