The Revit 2018.1.1 hotfix was released last week and solves an API issue that was already being discussed in the Revit API discussion forum.
Further, Gui Talarico updated the online Revit API documentation for Revit 2018.1:
- Revit and Revit LT 2018.1.1 released
- CropBox setting in Revit 2018 API fixed
- CropBox setting workaround
- Revit 2018.1 API documentation online
Revit and Revit LT 2018.1.1 Released
Revit and Revit LT 2018.1.1 product updates with the build number 20170907_2315 were released last week via the accounts portal and the Autodesk desktop app.
Here are links to the corresponding patches and documentation:
- Revit 2018.1.1 hotfix patch
- RVT Readme
- RVT Enhancement Document
- Revit LT 2018.1.1 hotfix patch
- RLT Readme
- RLT Enhancement Document
These hotfixes target all prior Revit 2018 updates, including Revit 2018, Revit 2018.0.1 hotfix, Revit 2018.0.2 hotfix and Revit 2018.1 update.
CropBox Setting in Revit 2018 API Fixed
The update fixes a couple of important issues, of course.
The only API related one is described thus:
- Fixed an issue so that the extents of a crop box are correctly set using the API.
It was discussed in some depth in the Revit API discussion forum forum thread on setting CropBox for a 3D view with Revit 2018:
Report 1: I am getting a different result with 2018 than I was with 2017 and previous versions of Revit.
Dim oBBoxCropView As DB.BoundingBoxXYZ ' do some stuff to create required bounding box. Dim V3D As View3D V3D.CropBox = oBBoxCropView
The code for creating the bounding box results in an identical BoundingBox, but when applied to the view crop box, results in very large max and min extents.
Has anyone else experienced this?
?oBBoxCropView
{Autodesk.Revit.DB.BoundingBoxXYZ}
Max: {(43.355956267, 0.075662107, -0.100000000)}
Min: {(21.252267057, -21.180810247, -1000.000000000)}
?V3D.CropBox
{Autodesk.Revit.DB.BoundingBoxXYZ}
Max: {(43.355956267, 0.075662107, -0.100000000)}
Min: {(21.252267057, -21.180810247, -1000.000000000)}
But with Revit 2018, using the same values for oBBoxCropView results in an invalid cropbox for the view.
?V3D.CropBox
{Autodesk.Revit.DB.BoundingBoxXYZ}
Max: {(-1000000000000000019884624838656.000000000, -1000000000000000019884624838656.000000000, -0.100000000)}
Min: {(1000000000000000019884624838656.000000000, 1000000000000000019884624838656.000000000, -0.120000000)}
After further investigation, I found that ensuring that the new bounding box assigned to the View3D's cropbox has the same transform assigned to it as the original crop box corrects the crop setting. In prior versions of Revit, the Min and Max coordinates would stay the same after assignment to the CropBox property. However, in Revit 2018 it appears that if the bounding box Transform does not match the View3D's crop box, Revit transforms the Min and Max values upon assignment to the CropBox property.
Hard to tell if this was a silent fix to incorrect behaviour in prior versions or if it's a bug in Revit 2018....
Report 2: I have also had this problem in Revit 2018. One of our add-ins crops a 3D view to the extents of a section box, which has worked in all prior versions of Revit until now (2018). The crop seems to be off by a variable amount depending on the location of the section box but it's not particularly consistent. It tends to be off by about 10 feet or so in X and Y directions...
Report 3: Section Box in Revit 2018 is indeed not working. I am having the same experience as fellas above. Code that used to work just fine in 2017 is not working in 2018. There are no errors or warnings, so I am not really sure what the issues are. My section box values look ok when I am debugging, transactions all complete, but when I open the view created, section box is off in space, even though its BoundingBox min and max would indicate that it's located properly. It's all very strange behaviour.
Answer: Happily, as said, this issue is resolved by the new update.
CropBox Setting Workaround
Workaround: Immediately before the release of the fix, CaptainDan provided the following workaround:
Just thought I'd check in to see if anyone else tried the workaround (that worked for me at least) for this bug?
What I originally did (and what worked in prior versions) was create a new BoundingBoxXYZ, set the min and max appropriately and assign this to the CropBox of the section.
In Revit 2018, after playing around with the same code, I found that as long I additionally set the transform of this new BoundingBoxXYZ to be the same transform that the original CropBox has, then the Min and Max don't change and appear correct. I haven't had any issues since this workaround and the tool that uses this code has been in use for some time now in our workflows without issue. Is everyone sure they're setting the Transform property appropriately?
Confirmation: Thanks for the feedback, Dan; you are right, if I change:
Dim oBBoxCropView As DB.BoundingBoxXYZ = V3D.CropBox
To the following, the extent is set correctly within my test sample, I will see what happens in my main application.
Dim oBBoxCropView As New DB.BoundingBoxXYZ oBBoxCropView.Transform = V3D.CropBox.Transform
Revit 2018.1 API Documentation Online
As Gui Talarico pointed out in the Revit API discussion forum forum thread on Revit 2018.1 API documentation:
RevitApiDocs.com has been updated to include the latest 2018.1 API:www.revitapidocs.com/2018.1
Ever so many thanks to Gui for maintaining this invaluable resource!
