Project Clean Up - Script Failing in Background Document

Hi All,

I have a script which is doing the following.

  1. Open project in background.
  2. Delete all sheets not on sheet lists.
  3. Delete all views not on sheets.
  4. Purge
  5. Save as new central file.

The script is working perfectly fine when I run it in the active document, however when I choose an existing document to open and run the script on, the part of my script highlighted in pink fails.

This part of the script uses the Views.IsOnSheet node by Archilab to create two lists of views: IN) Views on Sheets & OUT) Views not on sheets. When run in the active document this works perfectly fine, however when run in a background document the Views.IsOnSheet node is returning all false values, even though many of the views are placed on sheets (see image 1).

I’ve been troubleshooting this for a while and can’t seem to figure out why it works in an active document but not in a background document. All other parts of the script function as desired with either approach.

It’s not the end of the world because I could open the desired project and run the script like that but it would be nice to have it run in the background as I’d originally planned…

Any thoughts on the topic would be greatly appreciated.

I’ve attached the script and an image of it below. If anyone requires any additional information just let me know.

Thanks in advance.

Additional Packages Required: Archilab, GeniusLoci, Rhythm, Orchid, Clockwork.

Milestone Supersede Wizard_X1.dyn (78.1 KB)



Looks like most of @Konrad_K_Sobon’s work uses this line:

doc = DocumentManager.Instance.CurrentDBDocument;

I’ll let him confirm my assumption (since we’ve all learned a thing or two about talking about how others codes work).

The source for my assumption (and a great learning resource for anyone moving into Dynamo development) is the Archilab GitHub site, specifically here:

As you might expect from reading the above line, this means those methods will only work on elements in the active document, not ones processed in the background.

For me this is one of the horrors of background processing and why I am not a fan in general (and have actively steered away from it). You don’t see what changed in the file(s) as you never even see them. Add in the horrible idea of a view element actually existing in the open document with a matching element ID, and you run the risk of editing stuff in document 0 not the background one. Lastly if something goes amuck in the background processed document there is no undo (the background document was saved and closed while you weren’t looking). That said I do see the reasoning for wanting this.

If you do decode to work on background document processing, make sure that all nodes are built for background processing - the presence of a ‘document’ input on any node which interacts with Revit elements is usually a strong hint to consider - just be sure to wire that input consistently and that data stays clean and no filters are applied incorrectly.


Hi @dynamo_den,

Keep in mind what @JacobSmall wrote and use the Collector of PlacedViews node for your part 3 Delete views not on sheets.

1 Like

Hi @JacobSmall,

Thanks for the in-depth and informative reply - really helped me get my head around the core reasoning as to why the script was working in the active document and not when background processing.

One day I hope to learn to python script and ‘reverse-engineer’ a node as you describe, but for the time being I’ll make do with @Alban_de_Chasteigner’s suggestion.

Thanks again for the response! Helpful as always.

1 Like

Hi @Alban_de_Chasteigner,

Thanks! This workaround is perfect. Works a charm.

You actually confirmed the name of this package for me on another post and I’ve been very impressed with it - some very handy nodes in there.

1 Like

Hi @Alban_de_Chasteigner,

I fixed the script as you suggested and it was working perfectly fine a couple of days ago.

However now when I try to run it the Get all views node isn’t returning any values for sheets and thus the script is now failing…

Any suggestions?




I actually managed to figure this out in case anyone comes across the same thing…

The Applications.OpenDocumentFile node from the Rhythm package was outputting the document as a string.

Not sure what would cause this to change over the course of a couple of days?

I was able to workaround by using the Document.BackgroundOpen node from the Orchid package, as pictured. This outputs a revit file.


Hi Deniz,

You’re rigth. @john_pierson modified his nodes in the Rhythm last update to return the title of the document.
Unfortunately my nodes are working for the moment with an input document.

1 Like

I did. :disappointed:. The reason this change happened is because of the errors outlined in the following threads: (I specifically demo the crash in this thread and it is an icky crash)

In short, if you return the raw Autodesk.Revit.DB.Document from a node like the node you are showing, you are most certainly going to run into crashes any time you are in a run mode other than manual, (and even then, it can still crash).

I am currently working on another node that will retrieve the Autodesk.Revit.DB.Document by name to enable Rhythm node’s use with other nodes that require this input. But I want to be sure to do this in a way that prevents crashes which might be difficult…

FYI, if Orchid is working for you right now, then feel free to use that until I can catch up with my fix.

Also, I try to highlight changes on the Github as I develop the package as well. :slight_smile:Application and Document Bug Fixes · johnpierson/RhythmForDynamo@3e3fa88 · GitHub

Most of the most popular Dynamo packages are open source, so keeping an eye on the development is probably a good idea too :slight_smile:


@Alban_de_Chasteigner, @dynamo_den, I guess one question I have is, what is the likelihood that you would be running something like this in Automatic Run Mode? That seems to trigger the crash that I referenced.

I might be a rare case, but I run on automatic mode very often since it is the default (and I like to live dangerously). :grin:

1 Like

A mistake of inattention is always possible. :sweat_smile:
I think the crash may also occur if the Revit document is not closed at the end and the graph is run again.


Appreciate the info! I will check out the options we have and report back. :male_detective: :slight_smile:


Hi @john_pierson,

Firstly just wanted to say that I was watching your ‘Making the most out of the Dynamo Player’ webinar on youtube today. Your content is amazing and inspires me to do better - thanks!

I see your reasoning for modifying the node in question - makes sense. I’m running this particular script through dynamo player on manual at the moment so had to go with the orchid node for now.

Good to know, I’ll endeavour to keep this in mind for the future.

Thanks for your in-depth reply.

1 Like

Quick update on this.

I revised Rhythm’s nodes to return the Autodesk.Revit.DB.Document to allow for use with other nodes. The other method I was using was very stable, but broke the shared package compatibility. :disappointed:

I went ahead and opened the following Github issue, #9682 to see if we can get some more info from the dev team.

But, in the meantime, my nodes will just force manual run mode once the close document node (from Rhythm only) is placed. (Not ideal, but it does offer some more stability)

The functionality demo’d below is in Rhythm v2019.4.25



Hi John,

Thanks so much for this. Apologies as this is probably a silly question but I’m still very new to Dynamo. My Applications.OpenDocumentFile node is still returning a string value. In order to update this node to the most recent version does one need to simply reinistall the package through Dynamo?

Is there a way to tell when the packages I have downloaded are out of date? Or do you suggest simply updating all packages periodically?

One last question, when your Applications.OpenDocumentFile node has a true boolean for the “Detach From Central” input, does this detach and preserve or detach and discard worksets? Is there a way to toggle between the two options?


Yeah, you will need to upload via package manager which will require a restart of Revit.

I can definitely add the detach and discard / preserve toggle! Will be on next release. :slight_smile:

All sorted… I had a couple of issues uninstalling the previous package but this was down to not restarting Revit.

Thanks so much - would be a handy option to have. I take it that currently it is detaching and preserving worksets by default?

Looking forward to the next release :smile:

Yeah, detach and preserve for now. :slight_smile:

1 Like