Topics to start the week:
Last week, Augusto Gonçalves hosted the Revit API Panel at AU in Las Vegas (search for 'Revit API Panel', 'Augusto Goncalves' or 'SD195990' in the AU session catalogue):
The panellists from left to right are Lijuan Zhu, Diane Christoforo, Rahul Bhobe and Miroslav Schonauer.
Here are the notes taken by Diane, session handout and recording:
Very many thanks to Diane for the valuable notes!
I reprint them here in full:
Here is a link to Revit Ideas.
Your request may already be there! Vote! Add new ideas!
If you want the API ideas specifically, you can use the API tag filter.
DirectContext3D draws behind elementsDirectContext3D show up in printingReferenceIntersectorAn interesting, recurring and fundamental issue of ever growing importance was raised in the Revit API discussion forum thread on automatic extraction of the database revives – ignoring the fact that we don't know what 'revives' might be (reviews?):
Question: I am currently working on an internal project that will eventually extract database overviews of all our projects modelled with Revit automatically every night, to be then presented in the form of dashboards to the various members of the company. My IT Director is currently working on the subject but not knowledgeable in the API Revit, and me too. I would like to save some time by asking in this forum who could guide us towards a solution.
Answer: Here are some suggestions on various topics:
First of all, you need to work through the material to help getting started with the Revit API.
Before getting started with the Revit API, you should acquire as much knowledge as possible about Revit from the end user point of view.
I would assume that you already have that :-)
Here is one very old analysis of integrating Revit with an external database.
Many things have improved significantly since then, and your target is probably quite different (and much simpler than) the one discussed there.
Still, that article might provide a few useful hints.
By the way, talking about dashboards and things:
I would strongly encourage you to look at a partially cloud-based solution, to provide convenient access to a much larger audience in a much more scalable manner, with access to a huge number of public domain JavaScript-based libraries that can vastly simplify your work and integration efforts.
Here are some links to information about my own samples integrating desktop and cloud, provided in the FireRatingCloud overview.
They are also already pretty dated.
Since then, Autodesk has made significant progress with Forge, and Forge design Automation for Revit is just around the corner.
Maybe that will provide the most efficient path forward for your project as well?
Good luck getting started and looking forward very much to continuing this discussion once you have gotten your feet wet.
Another even more fundamental and recurring issue
concerns when to use doc.Regenerate:
Question: I am starting to write an add-in in Revit that will deal with the creation of thousands of family instances, addition of parameters and its values on the fly. I have most of the bits of code required for the task, but I really have no clue on when to use doc.Regenerate or not (the less the better for best performance, and I understand that I may have to organize my add-in in order to minimize the number of calls).
I have browsed the Internet, including Jeremy's blog notes on the topic, but it still seems to me that it remains some kind of trial and error operation.
Are there any guidelines, recommendations or documentation on the type of Revit database update operations that require the use of doc.Regenerate inside a transaction?
Answer: Indeed, it may seem a bit like trial and error.
In general, however, it should probably be pretty clear.
Whenever a transaction is committed, Revit regenerates the document for you anyway, so you do not have to call it in that case.
That will take care of many situations.
The only cases that require explicit regen are when you make several different modifications within one single transaction, and/or query the model after some of them have been make.
In that case, you may be retrieving stale data, outdated information that requires a regen to take the most recent modifications into account.
In general, I would probably not make any calls to Regenerate until I notice that something is going wrong.
Just keep in mind what can go wrong when stale data is accessed and used, always check your results, and be ready to add a regen call in case of need.
If you have read and understood all the examples listed in the topic group on the need to regenerate, you should be well prepared to address your programming task, at least as far as this aspect is concerned.
Good luck!
Response: Thanks for the confirmation, Jeremy. It is more or less what I expected. I have some experience on AutoCAD programming, where there was also a need to regenerate from time to time (but I was more or less aware about the rules of the game).
I will re-read your blog inputs on the topic before getting deeply into the add-in and I will test sequences of operations to check whether they require a Regenerate operation or not.
Last and probably least important, I'll point out a minor update made to centre the forms displayed by RevitLookup over their parent.
This modification was prompted by issue #45 – Center parent for forms raised by TheKidMSX, who also provided the pull request #46 – Forms startposition correction including the fixes.
You can examine the exact modifications in the diff between release 2019.0.0.4 containing the fix and the preceding release.