When i try to duplicate sheets with views, everything go well until i choose to duplicate with dependent , the sheet of elevation always has a shift, never duplicate in place, i checked everything but i can’t find the problem, can anyone help please.
i’ll attach the file and the dynamo script in order to self test that. I repeat, the problem is happening only with the elevation sheet and when duplicate views with dependent option.
DUPLICATE SHEET_02.dyn (63.7 KB)
Project1.rvt (4.9 MB)
If you’re using BimorphNodes, duplicating as dependents creates sheets and views from scratch (rather than duplicating views using the methods available in the API). This allows the node to maintain the same view structure with trade-offs. I suspect your sheet title blocks are shifted from the sheet view origin so when the new sheets and elevation views are created (always at the origin), it results in a shift.
Check if that’s the case and if so, reposition the title blocks in the original views then try again.
No, the title block is in the same place, and if you downloaded my attachments just try to duplicate with detailing and the problem will not happen.
I alos tried to use bimorph node, but it is the same
You’re starting elevation has no crop region turned on.
When you duplicate as dependent, it automatically turns on a crop region. Just what Revit does, because the command was designed for splitting a large plan or elevation into sections.
So, the duplicated view is picking up the crop region which is off in the parent view. Then it turns it on in the duplicated view. And then it places the view. Since the views now have different centers - it makes sense they have different locations.
The simplest solution is to enable - even if temporary - the crop region in the parent view. Duplicate and then turn off the crop region where desired.
The code is working as one would expect. No bug. Just not as sophisticated as you want. So, you’ll have to make it smarter.
Unfortunately, this didn’t solve the problem also, i activated the crop region and tried again, but the elevation get moved also in the sheet? Can you please download the attachments and try yourself, maybe i am having a problem in my dynamo version or something
I’m sure it is the problem. If you manually turn on the crop and run the script, it does just fine and the offset when it doesn’t work is the difference.
But dynamo might not be processing in a linear fashion. The activation of the crop region has to complete and the view center can update before it is placed in the sheet. You don’t have the same control of process order in dynamo as you would with traditional programming.
Maybe interject a wait for (passthrough)) and check the view boundary and center before and after. Or maybe a manual transaction. I’ll give it a glance tomorrow.
I tinkered with it and haven’t gotten the node to do what you want.
However, calling the method from python works just fine. But you would have to have to handle naming and options separately.
Just another one of those reasons I’ve pretty much bailed on Dynamo. You are at the mercy of whoever wrote the node.
sheets = UnwrapElement(IN[0])
TransactionManager.Instance.EnsureInTransaction(doc)
for vs in sheets:
vs.Duplicate(SheetDuplicateOption.DuplicateSheetWithViewsAsDependent)
TransactionManager.Instance.TransactionTaskDone()
OUT = sheets
You can take that and dress it up with other inputs.
And I replaced the Revit node with the Bimorph node. Better, but there is still a slight shift in placement.
did you downloaded the files i attached, and try this solution.
Because, i turned on the crops manually before running the script, but the problem didn’t get solved.
the main problem is this slight shifting, because in our work flow, we do opening schedules with around 20 to 30 views in the sheets, each is placed in an accurate location in the sheet, so if there will be any tiny shifting, with no any logic from dynamo, then the whole node is useless for me, the problem is that i don’t get any logic of this problem. No any logical reason.
