Bit of a weird bug that I’m experiencing while trying to utilise the view.SetCropRegion node within a script which is also creating the views I’m trying to set the crop region of.
After getting the script to a certain point I starting having issues with the following error message displaying on any revit interfacing nodes:
Starting a new transaction is not permitted. It could be because another transaction started and has not yet been completed yet. or the document is in a state in which it cannot start a new transaction.
After an iterative process of of freezing portions of the script I tracked down the error maker to be the view.SetCropRegion node. As, if I freeze this node, I have no issues with the rest of the script and the elevations are created (albeit with an undefined crop region).
I’ve tried a number of passthrough configs as well as forcing a transaction.end but to no avail. Every time I get pushed this error.
I believe that in order to set the crop, the view and it’s associated elements need to first be committed to the file.
Pass the results of the WaitFor node into a Transaction.End node followed by a Transaction.Start node. This will commit the initial portion of the graph to the file before starting a new transaction to accomplish the subsequent actions.
Weirdly, what did happen is that the elevation markers were placed but once it got downstream to the crop set node which errored they disappear…spooky!
Seems I might have a case of elevational haunting haha.
I thought we were on 1.3.4 for R19 users but forgot that I’d upgraded us away form that ages ago (the version I’m trying to get this to work in is 2.0.3).
Apologies, I’m used to working in 2.6 this is in an earlier version for a project specific task!
Just an update to this post - The error was actually being caused by me feeding invalid bounding boxes into the BB input on the Rhythm node!
I overlooked this before as it was still outputting bounding boxes, it was only when I tried converting them to cuboids and it wouldn’t that I realised I had an issue.
This was exacerbated by the Rhythm node giving a ‘transaction error’ which sent me on a wild goose chase !
@john_pierson maybe this could be fed back into a revision of what is being caught / triggering that transaction error report?
Thank you so much for updating us. All too often folks leave this hanging and it is extremely unfortunate for others to not know what went wrong. As a package author, it also sucks when people don’t update us because we don’t know how (or if we need) to fix it and it comes up again.
Right now I am using Revit’s builtin methods to raise the error given to my node by the Revit API to you on the hover tooltip and coloring the node yellow.
I went ahead and added the following message for when you feed an incorrect crop box:
screenshot of original post of solution for reference.
