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.
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.
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.
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).
A mistake of inattention is always possible.
I think the crash may also occur if the Revit document is not closed at the end and the graph is run again.
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.
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.
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
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?
. 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)
