Until recently this all worked fine, until I came across a problem in a very particular scenario. I wanted to loop through RVTLinks elements in a model using a category filter, and then get the boundingbox data for them. The model was opened using the API's OpenDocumentFile. This resulted in the following complaint from Revit:
I sent a test app to A'desk and they replicated the problem. Apparently this is happening because the Revit API "doesn't support multi-threading", and there is an SPR logged for this. This is strange for several reasons:
1. I've been using multi-threading with no problems for a long time.
2. The same code works fine if I have opened the file manually, rather than through the API.
3. Surely every Revit programmer needs multi-threading, as inherently a lot of the things we do are at some point resource-heavy? Or do I have to go back to the old DoEvents()?
Hopefully I'll get a bit more info on this soon.
Posts
Are you sure you're not disposing of Revit objects before the background thread has finished processing them? You have to be VERY careful using Backgroundworker with Revit.
ReplyDeleteFWIW, threadsafe Revit API is no small feat given Revit's architecture. Don't hold your breath.
I think something being unavailable to my background thread when I'm expecting it to be is the crux here. But I'm using the same code I've used for umpteen months, and its only now that I'm trying to access a particular type of element, when all else is the same, that this error has arisen.
ReplyDelete"threadsafe Revit API is no small feat given Revit's architecture" - could you elaborate on this a little? :)
Hi Ed,
ReplyDeleteI have the same problem here when using multi-threading with Revit API.
when i made changes to the existing modal. For example
1)set CompoundStructure to the floor type and report the progress back to the UI thread
or
2)rotate the column using method .rotate() and report to progress bar in UI thread.
Do you get any solution for this problem. Any helps is appreciated. Thanks