topic Re: Deleting unpurgeable viewport types through API in Revit API Forum

Deleting unpurgeable viewport types through API

pieterschiettecatte — Tue, 14 May 2019 14:56:42 GMT

When you copy views (including schedules) from one project to another, it brings in the default viewport type of that project. That viewport type becomes unpurgeable. So if you do this with enough files, you get a whole bunch of unpurgeable viewport types in your project.

We have a few of these unpurgeable viewport types in our template and I'm looking for a way to clean this up without being forced to recreate the template, which would take me weeks.

Anyone any ideas on how I could achieve this through the API (if possible at all)?

Re: Deleting unpurgeable viewport types through API

jeremytammik — Tue, 14 May 2019 15:31:54 GMT

Dear Pieter,

Thank you for your query.

In general, you can delete any database element using the Document.Delete method:

http://www.revitapidocs.com/2019/dd023de2-cf2b-03ca-6f45-89b5e867fe92.htm

Have you tried using that on the viewport types you want to get rid of?

You should be able to determine their element ids somehow, e.g., using RevitLookup or other means, and then hard-code them into a call to Document.Delete.

What happens if you do so?

Best regards,

Jeremy

Re: Deleting unpurgeable viewport types through API

pieterschiettecatte — Tue, 14 May 2019 15:53:14 GMT

It worked.

Can't believe it was that simple.

For anyone coming across this topic through google:

First, find the viewport Type ID using Revit Lookup
- assign viewport you want to delete to a view on a sheet
- select the viewport
- use 'snoop current selection'
- doubleclik GetTypeId
- copy the id
You can use dynamo to do the deleting. See screenshot of the graph:

Two big warnings though:

if you have views placed on sheets using that viewport, they will be deleted from the sheet (to be expected I guess)
however, this one is a lot trickier: if you have schedules using that viewtype, they will be deleted from the file. Yes, from the file, not just from the sheet. And you might ask: I thought schedules don't have viewports ... I would say ... yes that's what I thought as well...

@jeremytammik do you have any suggestions on how to prevent this last issue? I have no idea how to change the viewport of a schedule? I can't even find a reference to it in RevitLookup. It seems other users have reported the same unexpected behavior as well: https://forums.autodesk.com/t5/revit-api-forum/unused-revit-system-viewports/td-p/7176217

My theory is this: when you transfer schedules, sheets etc from other files you also bring in the default viewport of that file. It seems that that viewport is forever 'attached' to those schedules/sheets now. When you use the API to delete these elements, it also deleted the schedules/sheets you initially brought over.

Re: Deleting unpurgeable viewport types through API

pieterschiettecatte — Tue, 14 May 2019 16:04:26 GMT

Wait a minute.

The problem is not just limited to schedules. It happens to all viewtypes.

For example: I brought in some drafting views from another model, which triggered the creation of an extra viewport type.

I put those drafting views on a sheet, changed the viewport type to my desired one, and then ran the dynamo script to get rid of the old viewport. All the imported drafting views were deleted from the file, although as far as I can see in RevitLookup, they no longer have a connection to that viewport type.

Re: Deleting unpurgeable viewport types through API

jeremytammik — Tue, 14 May 2019 16:24:02 GMT

Congratulations on the simple solution and sorry to hear about the serious complications.

One thing you definitely ought to monitor is the return value of the call to Delete.

It is a list of all element ids that were deleted.

If you want to avoid deleting other object (unexpectedly?), you should ensure that the list only contains one element, the id of the thing you want to delete.

Maybe the GetDependentElements also returns those additional element ids with no need to call Delete?

https://thebuildingcoder.typepad.com/blog/2019/03/retrieving-and-snooping-dependent-elements.html

Unfortunately, I have no idea how to clean up those unwanted dependencies before deleting the unwanted elements.

Maybe the viewport type does not contain any reference to the schedule, but only vice versa: does the schedule contain a reference to the viewport type?

Cheers,

Jeremy

Re: Deleting unpurgeable viewport types through API

jeremytammik — Tue, 14 May 2019 16:27:52 GMT

Unfortunately, the ViewSchedule ViewType property is read-only:

http://www.revitapidocs.com/2019/76bee86d-3c34-7ee1-4349-cd7abcbf3d78.htm

Re: Deleting unpurgeable viewport types through API

pieterschiettecatte — Tue, 14 May 2019 18:22:52 GMT

Hey Jeremy,

It's weird. It's not just the schedule viewtype. It seems to apply to all type of views.

When I purge the unwanted viewport types from my template, I lose about half of my views (a few hundreds details and schedules). I think all of the views were at some point transferred from other projects (or are duplicates of views that were).

None of these views are using the deleted viewport types though. And as far as I can tell, Revit Lookup doesn't show any relationships what so ever between the deleted viewports, and the views that are deleted with it.

I'm a bit confused by it really.

Re: Deleting unpurgeable viewport types through API

pieterschiettecatte — Wed, 10 Jul 2019 17:16:02 GMT

Update for everyone who's interested in this topic: PyRevit has a tool that makes the unpurgeable viewports purgeable. Not sure how they do it, but their code is on github.

Also, their approach doesn't have the side-effects of deleting views/schedules.

Re: Deleting unpurgeable viewport types through API

bsulliv — Mon, 20 Jul 2020 16:08:54 GMT

This absolutely works! I employed the "get all viewport types" block -> list create - > Element name. Pinned the output so that I can see which elements id's to type into the code block.

Well done!

Re: Deleting unpurgeable viewport types through API

Sean_Page — Fri, 17 Sep 2021 18:50:15 GMT

I am not sure why it happens, but I ran into this and wanted to figure it out and I was moving views from several old files into one and it was brining all kinds of junk with it. Here is the solution I came up with, however I am not sure why the Viewport Type retains dependency on the Views even through the VP Type was changed in the UI, but you have to complete a ChangeTypeId() on the Viewports to make it stick.

Embeded Viewport Type | Revit | Autodesk Knowledge Network

Re: Deleting unpurgeable viewport types through API

curtisridenour — Tue, 21 Dec 2021 22:12:56 GMT

This is to add on to the script from above. I needed to know which was the correct viewports to delete. Seems to work just fine. But it is a manual process to type in the ID number.

Thank You @pieterschiettecatte for the simple solution.

Re: Deleting unpurgeable viewport types through API

priscillia_champagne — Tue, 07 Jun 2022 19:04:53 GMT

For some reason, when I try to run this function with pyRevit, no viewports come up, although I do have a few in my project. Would you happen to know why ?

Re: Deleting unpurgeable viewport types through API

KEVIN_W_MAK_WSP — Sat, 27 Apr 2024 21:50:36 GMT

PyRevit did the trick by swapping the unpurgeable from one type to another. Does anyone know what the exact problem is? What is depending on that unpurgeable viewport type and what need to be done in the API? Thanks!

Re: Deleting unpurgeable viewport types through API

Moustafa_K — Sun, 28 Apr 2024 06:50:30 GMT

I've been studying the pyRevit code for purging viewports, and it's intriguing how the developer approached the task. It seems their aim was to gather a collection of all viewport types from the document. However, identifying viewport types directly posed a challenge because they lack a defined category or specific class. Instead, they are categorized under the ElementType class, which serves as a base class for all element types in Revit.

To overcome this obstacle, pyRevit implemented a try-catch mechanism. By attempting to switch a viewport instance type to another type, they could determine if it belonged to the category of viewport types. Once pyRevit collected these types, it filtered out the viewport instance type IDs from the potentially purgable IDs and proceeded to delete them.

Considering alternative approaches, one could explore the possibility of identifying purgable viewports indirectly by targeting existing parameters. For example, since ViewportType is a system family and all must possess the "Show Extension Line" parameter (BuiltInParameter.VIEWPORT_ATTR_SHOW_EXTENSION_LINE), we can use this parameter as a filter rule to identify all types that possess it. Fortunatly, this parameter is a bool parameter, which its value is either 0 or 1, then we can use (ParameterFilterRuleFactory.CreateGreaterOrEqualRule) and supply a value 0 for checking.

With a list of viewport types established, the next step involves iterating through each type to retrieve the associated viewports using the GetDependentElements(ElementFilter) method.

Here's an example to illustrate the process:

// create filterRule to be used in collection var rule = ParameterFilterRuleFactory.CreateGreaterOrEqualRule( new ElementId(BuiltInParameter.VIEWPORT_ATTR_SHOW_EXTENSION_LINE),0 ); // get all elements that comply to this rule var viewPortTypes = new FilteredElementCollector(doc) .WhereElementIsElementType() .OfCategory(BuiltInCategory.INVALID) .WherePasses(new ElementParameterFilter(rule)); // now for each viewportType find a viewport instance dependent List<ElementId> purgeableIds = new List<ElementId>(); foreach (var viewportType in viewPortTypes) { var viewports = viewportType.GetDependentElements( new ElementCategoryFilter(BuiltInCategory.OST_Viewports) ); if (!viewports.Any()) { purgeableIds.Add(viewportType.Id); } } // show a list of all purgeable Ids MessageBox.Show( string.Join("\r\n", purgeableIds.Select(o => o.Value.ToString())) ); // ... handle these ids

I just tested it on 2025, would be glad to know if there are some holes in this method.

Re: Deleting unpurgeable viewport types through API

KEVIN_W_MAK_WSP — Mon, 29 Apr 2024 14:46:48 GMT

Your code works on my end; it allows me to get all purgeable viewport types in the project. I can use the reverse logic to get all unpurgeable and get their dependent element Id's.

And thanks for sharing the path to the pyRevit purge viewport code. This is going to be a great help too!

Re: Deleting unpurgeable viewport types through API

Moustafa_K — Mon, 29 Apr 2024 14:51:05 GMT

so glad it helps 🙂

Re: Deleting unpurgeable viewport types through API

Sean_Page — Mon, 29 Apr 2024 14:57:00 GMT

Here is what I use to get Viewport Types. It may not be super language stable, but it works great for me.

FilterRule rule = ParameterFilterRuleFactory.CreateEqualsRule(new ElementId((Int64)BuiltInParameter.SYMBOL_FAMILY_NAME_PARAM), "Viewport"); ElementParameterFilter filter = new ElementParameterFilter(rule); IList<ElementType> viewportTypes; using(FilteredElementCollector fec = new FilteredElementCollector(doc).OfClass(typeof(ElementType)).WherePasses(filter)) { viewportTypes = fec.Cast<ElementType>().ToList(); } return viewportTypes;

Re: Deleting unpurgeable viewport types through API

Admin.CTI — Thu, 26 Mar 2026 21:29:08 GMT

I have the problem that when i remove some of the viewports, other stuff gets removed, such as Sheets or legends, even when before the removal i reassigned every view to a valid viewport not to be removed. Anyone have a solution for this?