Copy Views to Document on file


#1

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.


Close Background Revit Files
#2

you cannot do anything with un-open files… a file needs to be open to do anything in it one way or the other.

what you can do is opening files in the background and load view into them one at the time and then close the file on exit.


#3

yea sorry about it that is what iam looking for ,I already have a document in background.


#4

Now the problem is the views loads into current document rather than the one open in background.


#5

Right, then this might help you. Nodes are from my package.


#6

thanks a lot i will give it a try at once.


#7

May I know the package the “Document.Transfer” node belongs to?


#8

click the icon of my profile!


#9

@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.?


#10

I have made a beta release including your request… please test it and give me feedback if it works :slight_smile:
https://github.com/erfajo/OrchidForDynamo/tree/master/Builds


#11

@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?


#12

Well… I am working on something else, so I coded this node out of the head without testing it. Things I haven’t tested thoroughly is released as “Beta”.

In other words, I didn’t know this side effect, and to my knowledge is it not possible to turn a background open document into the current document. if my node does that, then it is a completely new (exciting) ball game.

Thanks for the feedback, I will see what can be done when I have finished my current work.


#13

Is that so but,
It did change and i noticed that dynamo soon after the node executed said.
"Dynamo is not pointing to document "


#14

I will check it asap…


#15

This has been the case since the very early Background Open nodes (:point_left: 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)


#16

First, to my knowledge is using opening documents in the memory something very widely used and it gives no problems, none what so ever… If you remember to clean up afterwards.

@john_pierson, What you show is an expected error…
https://thebuildingcoder.typepad.com/blog/2010/03/using-processstart-to-open-a-project-or-family.html
As Jeremy writes, the document is only open in memory and not shown to the user… then removing the “open document” will fail for the “close document”… no news.

Therefore should there not be any so-called danger in using my BackgroundOpen node or others…

However, this oddly reply by @john_pierson made me interrupt my other work, even I don’t have the time for it…
I found the error and it was my bad… It was me being to fast in coding from my head without testing.
It had nothing to do with BackgroundOpen as expected, it was me forgetting to close the transaction properly… really rookie mistake.

I am so sorry.

The Beta build is updated and it is initially tested this time…
For now do I need to return to my work, but if you @saju_autodesk find anything else, could I then ask you to PM me, so I don’t get other oddly comments?


#17

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. :+1:

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. :roll_eyes: The correct way of doing this in non-Dynamo applications is to OpenAndActivateDocumentFile.