@GavinCrump I have both the PyRevit version working and the Dynamo version. I am still learning PyRevit but so far I am enjoying it. I will probably adjust some of the script s I learn and will post more when I have an update.
1 Like
We can certainly do that, if you can confirm that a sizable percentage of the user base utilizes a single standard, which isn’t the case. As an example I once wrote some code to automatically number sheets for an company with an office in the Boston area, and a week after I finished the project the same company had an office in NY contact me to build a the tool to a completely different numbering standard…
As a result of the lack of standard here, the Revit team can’t really build a specific tool for the case, and a generalized tool wouldn’t accomplish the needs of most. Fortunately the Revit team does provide Dynamo and the API for users like yourself to build tools which support your needs, and with the ease of Dynamo if you can’t do so yourself you’re able to utilize code provided by others (ie: Gerhard’s samples above) or procure your own via the app store or other means.
Some words of caution re: updaters:
- They require an event to trigger the execution; since Dynamo doesn’t have an integrated event listener or a way to configure such the updater will not work well if at all there (baring some stability concessions which personally I wouldn’t recommend). PyRevit (or better yet a full add-in) is a better solution here.
- Updaters and event listeners slow down Revit. The more you have, the slower it will get. This won’t matter in testing, but on workshared projects with many people in mixed environments it certainly will.
- Updaters degrade stability of the session (similar to above), doubly so when not implemented well. Exercise caution here.
- Updaters will not ensure everything is renumbered correctly due to the nature of worksharing and not everyone running the same updaters at the same time. having a ‘verify names’ automation should still be part of your QA/QC process (and if that’s the case, there is less value in the updater to begin with).
1 Like
@jacob.small I get it. and thanks for your reply. The fact is I have been using the paid add-in since 2010 I think. The naming convention to me should be standard setting without the need to customize it with just a simple prefix of Detail Number/Sheet Number. The fact that users want more customization is always going to be the case.
As of Revit 2023 there is an Icon to the left of the view that is a filled square if it is on a sheet and unfilled if it is not, and there is an option that can be turned off. This is a great step in the right direction. If beside the filled square there was an option to reveal the detail/sheet number listed that would also work without an add-in needed and would not be tied to the view name or title on sheet name in Revit. The main reason we use it is that we tie it to the view reference tool in our sheet/detail notes and for the longest time had no search bar and now it does.
I used to put wish list items in the Augi forum years ago. Like a grade beam family/tool that schedules in the foundation category and not just the beam category, so in that case yes, all structural Revit users would use that tool.
As for PyRevit and python in general I am following tutorials and it seems to be the way to go and is strait forward. I agree the in my many years of using Dynamo things tend to break and other issues arise.
1 Like
It is standard. The standard is not including the sheet number and detail number, as that is many orders of magnitude more common than having the suffix/prefix. 
Kidding aside, the idea of hovering over a view and having a tooltip telling you what the sheet and view number are is a great wish list item for the Revit team, and it likely could be added without too much difficulty. I don’t know if the AUGI forum is monitored still, so adding it to the roadmap here is likely a good call. I know those are monitored closely.
1 Like
And how this works with Dynamo!
As soon as the updater is registered there is no need for Dynamo any more, it can be closed.
![[video-to-gif output image]](https://global.discourse-cdn.com/business6/uploads/dynamobim/original/3X/c/6/c6b73f665bab1a618e98d93de7c1e2b6e37d7b57.gif)
It´s exactly the same procedure as with pyRevit. The code is only ran once to register the updater.
But revit is a little sensitive if you don´t unregister before closing the project.
This is (luckily) a highly specific trigger that fires only if a viewport is created or if a detail number is changed. I´m not expecting performance issues from that. Other cases may not be triggered as specific, for example to trigger the change of view range settings a trigger must be set up that fires at any change of any view, that will not work out.
1 Like
This is the sort of thing which I was referring to. There will be sensitivities to this process in the Dynamo context.
1 Like
In a Project with 4000 views the updater produced a little lag when placing a view on a sheet. The lag was not too bad but it was really annoying because the view was placed with an offset when you moved the mouse.
I assumed that this lag was because of the high number of views in combination with the (multiple) view name checks I´m doing to avoid errors. So I asked ChatGPT for help and made the following changes:
Here’s what you can do to improve the efficiency:
1. Optimize the View Collection:
Only fetch views that have the potential to have the same name as your new view. For example, if you’re naming FloorPlans, you could just fetch FloorPlan views.
2. Use a Set for Faster Lookups:
Sets in Python offer O(1) average time complexity for lookups. Before the loop, create a set of all existing view names:
existing_view_names = set(view.Name for view in existing_views)
Luckily in Revit views with different view type can have the same name! I didn´t know that before. This allows me to filter for view type. With these 2 improvements the updater now runs without a noticable delay 
1 Like
So, I am using ChatGP4 for help with writing the code and I have a partially working script so far. Currently the script copies the current view name to the title on sheet. The next step it prefixes the ‘View Name’ with Detail Number/Sheet Number. Example (1/A101 - Floor 1). Note the ‘Title on sheet’ name does not have the prefix. Currently it does update the prefix as the view number changes. Frankly I could stop there and have just a push button that collects all views on the sheet and adds the prefix and not have it auto update. That said I would like for it to do the same thing when I change the sheet number or the title on view again. Currently I cannot get it to update the prefix when I do either of those modifications. Here is the code.
View_Renamer_script.py (6.1 KB)
Hey @Shaun_Peppers ,
Oh thanks for reminding me that I also have to trigger at sheet number change, i forgot that!
So whats your problem, do you get an error when running the code? Then you have to look in the journal file, there you will find the reason for the error. Or is just nothig happening?
Yeah I will need to look in the journal file. Nothing happens whne trying to update the sheet name and view name and I just keep going in circles with ChatGPT. I will investigate more when I get time.
I´ll check it out tomorrow, currently I´m well practiced in getting these codes to run 
Your updater gets triggered if a sheet is created, that is wrong, you have to filter sheets out like that:
if view.ViewType != ViewType.DrawingSheet and view.ViewType != ViewType.Schedule:
viewport = element
else:
viewport = None
Then you have to add a trigger for the sheet name:
# Create a filter for sheets
sheets_filter = ElementCategoryFilter(BuiltInCategory.OST_Sheets)
# Get the ElementId for the sheet name parameter
sheet_name_param_id = ElementId(BuiltInParameter.SHEET_NAME)
# Add trigger for the modification of the sheet name parameter
UpdaterRegistry.AddTrigger(updater_id, sheets_filter, Element.GetChangeTypeParameter(sheet_name_param_id))
Then all views on the sheet have to be collected for renaming.