Is there any way to copy views from a Document to un-open ( Document from file path) document.
Like the Documents.CopyElementsFromDocument node except that i want to copy to instead of copy from.
yea sorry about it that is what iam looking for ,I already have a document in background.
Now the problem is the views loads into current document rather than the one open in background.
thanks a lot i will give it a try at once.
May I know the package the “Document.Transfer” node belongs to?
@erfajo thanks a lot
The document.transfer node transfers from source doc to current doc but I am looking for
transfer from one background document to other do you have some node for that.?
@erfajo thanks a lot,
It worked fine for me but wanted to point out that it takes you to the target document after transfer and I wonder how to shift back to my current document can this be added to the end of your script.
is it even possible to shift between documents with API?
Is that so but,
It did change and i noticed that dynamo soon after the node executed said.
"Dynamo is not pointing to document "
This has been the case since the very early Background Open nodes (
blog post from 2016) from Rhythm that were in Python. Nothing new discovered here.
I really do not believe that Dynamo was made to work this way and when a document is opened in the background in the API, sometimes it triggers Dynamo’s event handler to switch documents. You may have also seen this from time to time when switching files in the UI with Dynamo open.
In my testing I have found that this is not always reliable, nor is it always the case. This is partly why I slowed down development on my background opened document nodes. I wanted to be careful about making nodes that put Dynamo in a super weird state that resulted in hard crashes accidentally. I actually warn my users to only run background nodes in manual run mode since it seems to help.
(Demonstrated in the script below)
That all being said, the Background Open nodes that you are actively developing @erfajo are really nice and offer a lot of functionality that is strongly desired. The main consideration for end users would be to use a manual run mode or to be aware that Dynamo might need “refreshed” from time to time.
(Edit: I was actually considering embedding logic into background document nodes that switch Dynamo to manual run mode on placement, but that felt odd as well)
3 Likes
In a typical scenario. You must remember that Dynamo is not typical. It is working in a very interesting way within Revit while inside of the Idling event. Even if what my GIF demonstrated “was out of the norm”, it is most definitely something that can happen to any user. Which makes it worth considering as a package developer.
To simply dismiss that as “expected behavior” is irresponsible in my very honest opinion.
But, I thought I would share my experiences with those processes since this community is for sharing our discoveries and our struggles. I look forward to seeing what you find with your continued exploration. 
Also, that link you included is mimicking a double click on a Revit file or on the Revit.exe itself. This is not related to this discussion on using the Revit API’s background open methods within a valid Revit application context. 
The correct way of doing this in non-Dynamo applications is to OpenAndActivateDocumentFile.
5 Likes