Important news coming for structural developers, further development in RevitLookup, notes on extensible storage and JavaScript:
Any versus CountWe have just added a new item to the Revit Public Roadmap announcing a new API for analytical modelling in Revit. This is quite an evolution (if not revolution, as the old one will be deprecated). Please take a close look at it if you are interested in this area.
New API Analytical Model
New API to enable direct control of the structural analytical model that allows developers to operate independently the creation and modification of analytical elements, offering simplified implementations that work in abstraction from physical elements.
To further track progress and news on analytical modelling, you are also invited to apply to join the Revit preview project.
Just like the Revit Idea Station, the roadmap enables you to vote for the roadmap items that have the greatest importance for your specific projects.
We received praise on Twitter and LinkedIn for the new modeless RevitLookup:
Thank you for your appreciation, everybody, and yet again a huge thanks to @NeVeSpl from me too.
One interesting little item that came up after
the subsequent RevitLookup cleanup questions the use of the generic Any method to check for an empty collection
in issue #113 – error snooping family type from project browser,
where Roman @Nice3point points out:
It would be nice to remove this filter and replace
ids.Any()withids.Count > 0. This will improve performance, asAnycreates a newEnumerator. Proof:
I agree that sometimes code readability is more important, but in this case additional lines or conditions are not added. The difference in speed is 1200 times with memory allocation =(
It takes 27 NANO seconds, and 40 Bytes in instruction that is invoked only once per use case 🤣.
Many thanks to Roman for this little suggestion and benchmark, and much more so for all his other outstanding work recently improving and maintaining RevitLookup!
Before we escape this topic, yet another little RevitLookup update bears mentioning:
Luiz Henrique @ricaun Cassettari submitted pull request #115 to add keyboard escape to close form:
After the Modeless update, the Escape button stop working. This PR reenables the Escape keyboard feature; now the focused form closes if the Escape button is pressed, and the Owner regains focus.
Published in RevitLookup release 2022.0.2.4.
Many thanks to Luiz Henrique for catching this!
Moving away from RevitLookup to more general Revit API topics, @aalondoqor ran into a problem similar to the one reported two years ago in the Revit API discussion forum thread on a Bug: Unable to open Revit 2019 model after saving custom schema in Project Info.
With the help of the invaluable advice provided once again by Richard RPThomas108 Thomas, it turns out not to be a bug after all...
The original problem description includes an an archive with a project CS.Revit.TestLib.zip to run in Revit 2019 with a README.md specifying the problem reproduction steps.
In the new iteration, @aalondoqor asks:
Question: Hi, can you solve this bug?
Answer: Does the sample material provided previously exactly cover your problem as well?
Response: Yes, is the same case exactly.
Answer: You have to be careful with Extensible Storage; it can cause these issues.
I experienced the same issue with that sample in Revit 2022 when upgraded;
I made the enclosed changes to Application.cs and no longer experienced the problem.
Essentially, the changes consist of:
ByRefSchema.Lookup(SchemaGuid), rather than just supplying GUIDnew Entity(Schema) instead of new Entity(GUID)ExtensibleStorageFilter.I guess the 'archive error' failure to open should be investigated regardless, but comparison between enclosed and original may indicate the cause.
The sample includes producing a library in netcore3.0 and dotnet47.
I upgraded to dotnet48 and dropped the netcore3.0 version.
Due to referencing the Revit 2022 API, I had to change aspects related to DisplayUnitType.
Updated solution enclosed, not original:
When Extensible storage was introduced, we all went through a small period of time when we were using it wrong and we didn't see the implications until later (often the next year when we updated the add-ins but had the old schemas). So, will always be an important subject to developers with limited experience of it.
I have to thank The Building Coder, because the majority of my knowledge of this subject is due to the AU handouts by Jeremy Tammik that are available on the web.
They may not incorporate the latest ways of obtaining Schema's etc., but the process is still outlined correctly.
From what I've seen, people often get into difficulties when they go too far away from these ways of doing it.
I think the general rule is, don't hold onto objects and keep interactions as finite as possible.
The Revit SDK also provides a good basic example under SchemaBuilder.
If you conclude my fixes solved the issue or even if you demonstrate a better way (I did rewrite in a bit of a hurry), I would be happy to read that on the blog.
We could ask Autodesk to find a more graceful way for Revit to handle the issue, but I think that is perhaps easier said than done (is a memory issue, is not new, we all have our part to play in terms of program stability).
Often if you can't open a file, it may be possible to open it on a Revit version without the add-ins.
The add-in in question was creating the schema OnStartUp, so would have already put something in memory before the document with the conflict was opened (could open it without the add-in when I checked later).
Response: Thank you all very much, I fixed my problem with the example file supplied by RPTHOMAS108; thanks for sharing your knowledge.
Moving away from the Revit .NET API to the web, I have used jQuery in the past and would maybe continue doing so if I had not just noticed this article explaining why outdated jQuery is still the dominant JavaScript library.