Hi
I’m using the ‘viewport.setboxcenter’ node from Rhythm (@john_pierson) but am having some issues with it not triggering. Im trying to modify both the floor plan viewports and the section viewports but the issue is that only the floor plan viewports are moving. Only once I re-wire the section viewports are they triggered.
I’m not sure if this is a limitation of the Rhythm node or not. I suspect the issue has to do with an active transaction somewhere. However, I’ve tried the following but its not working:
- Added ‘transaction.end’ before ‘viewport.setboxcenter’
- Added a Passthrough node (Clockwork) for both the viewports and points (as per the floor plans)
- Combining the floor plan viewports and section viewports into a single list and use only a single ‘viewport.setboxcenter’ node.
- Dasiy chaining the ‘viewport.setboxcenter’
The only thing working, is forcing the node to re-execute by re-wriring.
Any ideas how to solve this?
The code for Viewport.SetBoxCenter is here and is pretty straightforward. This has come up once or twice before and it has to do with transactions in Dynamo.
Have you tried both a Transaction.End and Transaction.Start before each of the setBoxCenter nodes?
1 Like
May also want to combine that into a single sequence via a WaitFor method (a combination of what was done before).
Thanks I’ll give that a try but can you elaborate on this a bit more… If a custom node is already starting and ending a transaction within a node, why would there be a need for ending and starting a transaction BEFORE connecting to that node?
Trying to understand in general how Dynamo deals with transactions. Because as I mentioned, combining into a single list and using just one node doesn’t work which doesn’t make sense to me if the problem was due to a transaction.
Dynamo tries to wrap all transactions in nodes within it in one transaction, (for nodes using Dynamo’s built-in TransactionManager). This causes problems in Revit because of regeneration and things like that. (And probably a whole lot of other reasons that I am not 100% sure of)
This is most problematic when we need things to be sequenced. (Eg. Creating a view, placing it on a sheet, locating the viewport).
Generally speaking, your specific problem sounds like something to do with transactions and sequencing and Dynamo isn’t liking it. The Rhythm node isn’t the limitation here as it is using the built-in Transaction framework. Adding a few Transaction.End and Transaction.Start nodes would more than likely fix the issue.
As a test, try adding some of these nodes to even a sample graph and observe the multiple Dynamo Transactions in the undo queue after.
4 Likes
Not sure anyone has the complete list… sadly. 
Thanks John.
It took a bit of fiddling but it eventually worked. I think the issue was upstream I was tagging elements and modifying the view’s crop box and somehow this was impacting the viewport for Viewport.SetBoxCenter. Adding in Transaction.End and then Transaction.Start worked.
@jacob.small are transactions documented anywhere in the Dynamo Primer? If not, might be a useful section to include.
They are VERY Revit centric, and more of a Revit API must learn than a Dynamo one. A series of nodes for transaction groups was something I contemplated for a hackathon a few years back, but the core integration with Dynamo for Revit made that quite an uphill battle I wasn’t going to get traction on by my self.
I’ll put the thought in my near term backlog, as there is a blog post there if nothing else. @solamour the D4R team may want to look into this as well - the ‘own’ this aspect of the integration, so the formal documentation should likely include their thoughts if not coming directly from the source. Similar thoughts on D4C and the like.
1 Like
Anytime I have needed transaction groups or more finite control of transactions in Dynamo, I end up using RevitAPI’s transaction class in Python or ZeroTouch nodes.
2 Likes
Definitely the way to go.
