Here are a couple of the interesting topics that came up in the last couple of days:
overrideJoins
argumentNumerous contributions with important RevitLookup enhancements were submitted since the flat migration of RevitLookup to the Revit 2022 API:
In the latter, Alexander @aignatovich @CADBIMDeveloper Ignatovich, aka Александр Игнатович, adds:
I fixed RevitLookup handling of extensible storage.
The Extensible storages
fields were broken:
Now RevitLookup also supports Dictionary
KeyValuePairs
lookup.
That is useful to view extensible storage entity data:
Plus another small improvement: each ElementId
could represent a model element id, a built-in parameter or a built-in-category.
For the latter two, it is much more useful to see an integer value instead of null
.
Many thanks to all contributors for your great enhancements!
In case you, dear reader, would like to add your own to these as well, please fork the repository, clone to your local system, modify at will, commit, push the changes back to your fork and submit a pull request for them to be included into the main code stream.
You can easily track and analyse the changes to see how each individual enhancement above interacts with main project by clicking the Compare
button to view the difference between
the individual releases.
My colleague Naveen Kumar @NK29 T is steadily building up his collection of solutions in the Revit API discussion forum.
He also migrated the Revit API Labs Training Material to Revit 2022. The latest release is currently 2022.0.0.2.
Many thanks to Naveen for his contributions!
The closely related AdnRevitApiLabsXtra have yet to be migrated to Revit 2022... coming up anon...
Prompted by both Naveen and the Revit API discussion forum thread asking for VisualStudioRevitAddinWizard 2022, I performed a quick flat migration of that tool to the new version last week.
The latest release is currently 2022.0.0.0.
Stefano Menci very kindly shared some useful research results in
his Revit API discussion forum thread
explaining what the overrideJoins
parameter does in CurveElement.SetGeometryCurve
:
The Revit API documentation contents
itself with the statement that the overrideJoins
argument provides:
an option to specify whether or not existing joins will affect setting the geometry of the
CurveElement
. Setting this parameter tofalse
is essentially the same as directly setting theGeometryCurve
property.
Stefano's research provides a little bit more detail, explaining:
I figured it out, so I will post the question with the answer anyway, for anybody interested (and for me, the next time I need it, because sometimes I'm a little forgetful):
The following code:
tx.Start( "Test 1" ); var plane = Plane.CreateByNormalAndOrigin( XYZ.BasisZ, XYZ.Zero ); var sketchPlane = SketchPlane.Create( doc, plane ); var p1 = new XYZ( 0, 0, 0 ); var p2 = new XYZ( 10, 5, 0 ); var p3 = new XYZ( 20, 0, 0 ); var p2Higher = new XYZ( 10, 10, 0 ); var line1 = doc.Create.NewModelCurve( Line.CreateBound( p1, p2 ), sketchPlane ); var line2 = doc.Create.NewModelCurve( Line.CreateBound( p2, p3 ), sketchPlane ); var line3 = doc.Create.NewModelCurve( Line.CreateBound( p2Higher, p3 ), sketchPlane ); tx.Commit(); tx.Start( "Test 2" ); line1.SetGeometryCurve( Line.CreateBound( p1, p2Higher ), < false | false >); tx.Commit();
Will return the following result:
Many thanks to Stefano for the analysis and explanation.
Sean Page of RDG Planning & Design shares another useful hint in the Revit API discussion forum thread on my Revit app can't find SQLite.dll, saying:
I ran into issues recently in 2022 related to references that previously worked. Turning on and using the
Fuslogvw.exe
assembly binding log viewer was a substantial help.
Thank you, Sean, for pointing this out!