As a method of determining if a Legend View is harboring the unwanted Text Style, simple select and delete all Legend Views and then check the 'Purge Unused' dialog to see if that Text Style can now be purged. In lieu of hunting for it, you could just change the Text Style (using the Type Selector) while they are all selected.Ĭheck your Legend Views - The above method does not cover these. If that count reads more than 1, then instances of that Text Style still exist in some Plan View. Railing Subcategories like Top Rails (and Handrails) will not be purged if they are part of a railing definition even if that railing is not placed in the project.That would indicate that the Text Style is in use *somewhere* in the Project.Ĭheck your Plan Views - this can be done globally by creating a Text Element in any Plan View of the unwanted Text Style, right-clicking on it, selecting 'Select All Instances' ► 'In Entire Project', and then checking the number in the selection filter in the bottom right corner.

Nor can they be deleted in the Family Browser (by right-clicking) until they are removed from the Stacked Wall definition. Basic walls cannot be purged if they are defined as part of a stacked wall, even if the stacked wall is not used.It is impossible to remove either of the Stair path arrow system families, despite the fact that most people only want to use one as their corporate standard.There are numerous examples, each of which behaves differently:

Where one family is referred to by another that is retained in a project, Purge will not remove either (even if unused). The elements in this phase would not be visible if they are demolished in the existing phase.ĭespite it being too easy to purge some things, it can also be hard to remove others: To get around this problem, I suggest creating a 'setup' phase that is earlier in time than 'Existing' and placing one of each type of mullion, door family, annotation etc that you do not want to have purged accidentally. The same goes for other annotation types like dimensions, text etc - although they are easier to reinstate.This means that most of your annotation standards can be blitzed in one command - and they are laborious to set up again. Typically you will actually want several different spot annotation types (at least one each for plan and elevation). Spot Elevation families it removes all but one unused family - so it will not remove the last one (it may not be the one you want to keep). Purge does does something a bit different with some annotation families: eg.It removes all unused types, including the last one of each mullion system family. Purge will remove some unused system families or types - like all those tricky corner mullions. Why not let just anyone run the purge command? Well, apart from the time it takes, it can remove important stuff from your project that is tedious to reinstate - here are some examples: I know that on some projects it can take half an hour to run the purge command, so it is annoying to have to run it three times. Or perhaps there is a technical reason for the inconsistency?Įither way, I am very, very happy that we can actually purge materials because it did not used to be the case a few years ago, and it was extremely tedious deleting materials one by one.

My guess is that different people coded the software for material purge, and they probably didn't follow the same rules. So Revit can do it all in one go if it wants to. It is not consistent with other aspects of the purge command - for example if you purge an unused group, Revit will also purge items that are in the group providing that they are unused elsewhere. Why does it do this? Well it seems unable to handle purging the materials and assets at the same time as their parent elements - it is all too much for it.

Revit delete text styles