Open, Editing and Saving a Document in the background

Hello,

I feel like as soon as I think I understand something, I get an error that I can’t understand. I’m able to use the OpenDocumentFile node to open a second file, save it and then close it in the background (while another project is open). The issue I am running into is it appears that if I want to edit the file while open (say, purge unused elements), the node does not like the ‘document’ input I am sending it. Apparently the file that I have open in the background is a Revit.DB.Document, but the node only wants a Revit.Document input.

I have a similar issue with other document-driven nodes, such as clockwork’s ‘All Elements of Category+’. The nodes never affect the document that I link into them.

The latest version of Rhythm has some nodes to convert between these two doc types.

@anordstrom ,

i had here a similar topic, packages from crumble are usefull

I can’t seem to find anything in regards to ‘crumble’.

Thanks, John. We haven’t upgraded to Revit 2023 yet…does this work for older versions?

2021 (maybe 2020)-2023

@anordstrom ,

just look under the package manager

Thanks—for some reason it didn’t show up the first time.

1 Like

Well, that node works great, but for some reason I just cannot figure out why any changes that are made are not through the secondary document but in the main Revit session. I don’t understand why the nodes are not affecting the background document that is connected into them.

2 Likes

Background processing is a complex issue. The recent discovery from @john_pierson on utilizing reflection to wrap the elements seems fairly robust, so I expect some significant gains in the simplicity here, but that doesn’t mean we won’t run into other issues as more of these workflows are adopted. One such issue may be leading to mis-aligned pointers due to the significant volume of page faults (when your RAM isn’t enough so the CPU has to move data to your scratch disc) which are likely present in this type of workflow. Can you post what you’re seeing with the cross-crossing of document stuff?

You may also want to consider moving your efforts to a single Python node, zero touch node, or another means to ensure you never have to marshal more than one document between nodes at a time.

Thanks. There really isn’t much to show—and I’ll be the first to admit that I may be in way over my head here. Below is my workflow:

  1. Actively Working in File ‘A’.
  2. I want to open up file ‘B’ in the background with the ‘OpenDocumentFile’ node.
  3. File ‘B’ appears to be loaded corectly in background
  4. Problem: Any subsequent nodes (which are fed the document output) only affect file ‘A’, not ‘B’ as expected
  5. So in the case below, the document.saveas does a ‘Save As’ to the already open file ‘A’, not the background File ‘B’.

Assuming you’re on the latest build of Rhythm?

This may be an issue with the reflection method which Rhythm has recently implemented, but more likely it’s something else as @john_pierson is super thorough with putting stuff like this out there. Which Revit and Dynamo for Revit version was this in? Perhaps it could require an update to the Document.SaveAs node (which I don’t think is from Rhythm), or that the wrapper for your particular combination of Dynamo and Revit is blocking the new node from processing correctly due to pointer overwrite or other issues. The “single python node” may be your best bet if you have an immediate need.

It does not seem to be the reflection method at all as the node is still returning Autodesk.Revit.DB.Document in the screenshot…


This is telling me that whatever node that is, Document.SaveAs is doing something else that is weird.

I see that it is from GeniusLoci and he has a fallback to just use the current document if something goes wrong.

FWIW, I have a save as option too, but it doesn’t have all the stuff you are looking to do I don’t think.
image


But I really wanted to make it clear that this is not a problem with the new reflection stuff @jacob.small

2 Likes

I will try again tomorrow. Is it possible that it is calling the saveas command before the file is finished loading?

As I experiment even more, I think a portion of the problem is that the ‘OpenDocumentFile’ does not appear to finish loading the file before these commands try and take place. A passthrough node does not appear to work with the OpenDocumentFile Node. Is there a way to confirm that the file is open before running further commands?

Hi,

You could wait to get the document name before saving the document.

2 Likes