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.
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.
I did. . 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.
@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).
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?