I have been teaching and using the hack to use railing supports in leiu of baluster or to use them for gates etc. Yesterday a client told be about an issue with Railing Supports, they do not abide by phasing graphic overrides. In cases where the supports are simple brackets (as shown below this probably isn’t that big of a deal.
However when you are utilizing support for balusters or for gates (as shown in the two images below) this becomes a big issue. This has been reported to Autodesk and I was able to reproduce the issue in both Revit 2017 & 2016, I didn’t test it in older versions of Revit.
One of the minor new features for Revit 2017 was the nuance of how pinning a tag works. In previous releases if a tag had been pinned it kept an individual from moving the tag but it moved along with the element it tagged. In 2017 when a tag is pinned it still keeps an individual from moving it, however it will stay in it’s given location as the element being tagged moves. Note: The leader only moves with the tagged component if the Leader is set to Attached End and not Free End.
This is a very welcomed new feature, I have been an advocate of detailing using tags in lieu of text but was always frustrated that if a detail item changed the tagged would move and have to be realigned. No more wasting time with this menial task
The new features that we received as part of Revit 2017 for View Range were actually part of 2016 R2, with one exception. In 2017 the factory gave us a 2 key shortcut (VR) to activate it. This is, maybe I should say was, one of my favorite new little features for this release. However I found a bug when using the shortcut instead of accessing it through the properties dialog. If you use VR to access the dialog you Must use apply dialog for it to work clicking OK wont accept changes. Aaron Maller and I also discovered that you can access the view range via VR even when there is a view template assigned. Simply applying the view template to the view wont correct the problem you must make a change in the view template and it will then overwrite the settings. These quirks forced me to no longer say this is one of my favorite small enhancements.
During my last Revit Radio session I was had made the comment that Material Assests can’t be purged out of a family. The discussion arose as I had found a bug in Revit 2017 that if you attempt to delete all the materials out of a family then Revit was just crashing. It didn’t do this on all families but specifically on View Title families, both OOTB and custom versions. Aaron Maller wrote in explaining me a work around to remove the material assest. This mornign I was gong to blog about his work around but wanted to first attempt to figure out why the family was crashing in the first place. My first troubleshooting thought was to purge the family and to my surprise we can now Purge material assests (This is huge for us content generating geeks). Not only that but it will allow us to purge all materials out of a family, it doesn’t leave default.
FYI purging the family of materials didn’t make it crash but deleting the material did. I stopped looking since this is a better option anyway.
I recently posted about the issues that will arise when upgrading a project from Revit 2016 to Revit 2017. Upon further investigating there is a significant quirk when comparing text to tags. I was updating a detail container file for one of my clients where they use mostly Keynote tags with a bit of text alongside for more clarifications. At first glance it may not be noticeable, however if you zoom out you can see a difference and if you make the a text value match the tag value it is easily seen on screen.
If you look closely at the screen capture above you may notice that the top line of text looks a bit more pixelated (ironically it was more noticeable in a screen capture then on the Revit screen). As seen in the capture below it becomes more noticeable the further you zoom out in Revit, it almost looks as though the text is bold and the tag is not.
To really make a comparison I typed a piece of text (shown in blue below) directly over the tag (shown in black) and as you can see the text is spacing, or kerning, is larger in text than tags as well as the height being slightly taller.
I had thought that maybe this was an issue with updating the project and the tag as well. I created a new tag from the 2017 template and the same thing occurred. I don’t envision this causing many issues with upgraded projects but something I think should be addressed by the Factory if future releases.