Auto Name Views on Sheets - PyRevit vs plugin?

Hello Dynamo Friends :slight_smile:

I am using a dynamo script to name views on a sheet with sheet name + “Section” + detail number. This for sure won´t auto update.
A company i worked at hat a similar plugin, that auto updated the view name with “@sheetnumber”, but didn´t work that well.

There are even plugins in the autodesk store that can auto name views: eganbimresources

For sure i want to build this on my own but it´s not the time for me to build my first plugin. So i stumbled across this post from @GavinCrump

So maybe it´s time for me to start using pyRevit?! Would it be possible to rename views always when a view is placed on a sheet, removed from a sheet or if the detail number is changed? What will the other users have to do to use the code. Installing pyRevit for sure, but will they have to do additional steps like manually activate that python script every time?

Doable in pyRevit or is this a classic plugin case?

Happy about any advice :slight_smile:
Kind Regards

Edit: Additional question, is this the event I´m after? ViewActivated Event
And will this also be triggert when changing the detail number?

I am not a user of pyRevit, but it should certainly be possible to use Events, however I would recommend that you look at Dynamic Updaters for what your trying to do. We have similar things in place (custom add-in) for when views are placed on sheets or views are created etc.

I guess one more thing to mention is that although it will be leveraging pyRevit, what your after is still going to be custom coding a solution tailored for your use case. So, unless you use pyRevit for other things as well, a fully custom add-in could be more lightweight, and user friendly.

1 Like

Second Sean’s thoughts. If you’re well versed in addin deployment and not deploying pyrevit then an addin is fine. If you’re more versed in Python and have capability to deploy pyrevit then a view changed or activated event might be infrequent enough to safely run this check. You could always run it pre-sync alternatively so that before a user returns their wrongly named views they get fixed and synced in.

1 Like

I think the python way should take me a week while the plugin method will take ma a year :smiley:
So I will definitely start with the python way and see how it´s going. Never heard of the Dynamic Model Updater, thanks for that.
Thanks for your replies!

Correct View Names are not really necessary for our workflow, we don´t need them to build filters or any other important stuff. So renaming views at syncing might be pretty much all i need.

1 Like

pyRevit is not a heavy weight application. it is really more of a platform than an application. Very fast and easy to set up. Can be installed at either the admin level or at the user level.

pyRevit uses “hooks” which provide access to Revit events. Much simpler to set up than an add-in.

Whether an add-in or pyRevit, I would plan event driven applications carefully. They need to be robust and foolproof. You have a limited list of events to choose from and you don’t want your app to be firing all the time and slowing down Revit. So don’t just add it to the DocumentChanged event unless you know it will take a minuscule nanosecond to run. Even a view change event needs to be carefully thought out.

pyRevit can do what you want.

I’ve got my view naming and placement management setup to run on save and sync. At those points it tidies up everything the user has done since the last save. (Plus north arrows on plan sheets, graphic scales, checks door numbers, sets existing doors to 45 degrees, etc, etc.) Again - program with execution time in mind. No one wants a 5 minute save because your programing is slow.

Don’t forget to give users some notification of what has done and log your actions for trouble shooting. This is the toaster form in pyRevit that you can click on and get a log of what was accomplished. no popup toaster - and the user knows something is wrong.


1 Like

Thanks for your reply aaron, I´m already making my first steps with pyrevit.

I have some more questions:
In pyRevit i can load python scripts that wll appear as buttons in the pyRevit Tab.
Is it correct that i can also use pyRevit to create a new Tab for my scripts, so that it looks like a real plugin?

And in the following thread someone says that writing a plugin with python is also possible without pyRevit. How would that work? Still so much things i don`t understand^^

Kind Regards!

Maybe check out my videos here which should how to set up a tab. Noting this is really more suited to the pyrevit forums vs Dynamo if we’re heading down this discussion path:

To run Python through Revit you generally need an application to interface with the RevitPythonShell which I believe is how pyrevit works behind the scenes. Python is generally not used outside a program without a wrapper/shell to run it, or an IDE.

1 Like

After my first days with pyRevit I´m really excited. I got my first hook scripts running, my first pushbuttons and I´m looking forward to integrate the dynamo scripts. It´s a really amazing tool. Also good that there is a explanation for deploying it to a team, still have to figure out all the pro´s and con´s but i really hope i can setup this for our team :slight_smile:

Deployment is simple. Set up a directory on your server and place all your extensions and bundles there. Use the pyRevit options on each machine to point to that extension directory. pyRevit . Settings >Custom Extension Directories. That’s all there is to it.

You can continue to add new scripts to the directory on the fly. Each time a user loads Revit (or reloads pyRevit, they automatically get the new stuff.

I keep two extension directories. One for the office and one I use for development. When I get something to the point I want to deploy - I just copy it over to the office directory.


1 Like

Ok so that would pretty much be the same method we use now for “deploying” the dynamo scripts.

But now whats the advantage of this CLI method?

That is more appropriate for larger organizations and those deploying customized pyRevit installations. For instance, if you want to pre-configure all the pyRevit settings and want to deploy all the apps locally.

The disadvantage of a centralized location on the server for scripts is that you have to be connected to the server. This might not be possible if you are off-site.

For small and mid-size organizations with limit IT support, I find the central server setup the simplest. We just do pyRevit installs to the user’s local app dir to avoid any admin password needs.

For a larger organization with good IT support and those that need deployment to systems not always connected to the network, using the CLI for deployment might be a better option.

Thanks for the explanation aaron, i already was afraid this will be complicated, but for me the CLI method will not be necessary :slight_smile: