Hello,
I am presently exploring executing a few Revit API scenarios to be executed via Rhino.Inside.Revit with a custom Rhino plugin. I am encountering some ‘broken’ behavior in some Revit API methods for file imports (DXF, DWG, SAT, etc) when they are executed within a Rhino.Inside.Revit context - namely with Revit Document.Import and FamilyDocument.Import methods.
My Setup:
Launch Revit, Start a new project document, and load Rhino.Inside
Open the Rhino Window
Run a custom Rhino command that executes a Revit API Import method (with Rhino.InsideRevit)
My Problem:
Using this setup, I am able access the Revit document/app/etc. I have succeed in executing some Revit API methods/transactions from Rhino as I expected.
Where it fails: When attempting to use the Revit API Document.Import() method, Revit returns a message “Not a valid file for DWG import (.dwg and .dxf files are valid)” - the file is indeed a valid file.
What is expected to happen: The exact same code and file succeeds when executed as a Revit macro or as a standard Revit API plugin.
Some questions
Are there known limitations (like this) documented anywhere for running Revit API methods through the Rhino.InsideRevit context? The only thing I could think of is that it seems that Revit’s import methods might use resources that conflict with Rhino’s causing strange failing behavior?
Am I missing a step to ensure that Revit API import methods function correctly when executed through Rhino.InsideRevit?
Are there any workaround available for this kind of issue?
Here is a code snippet:
Get the ActiveDBDocument from Rhino.InsideRevit
Begin a Transaction for importing a file
Set DWG import options and get a view
(FAILS AT) Perform the Document.Import() method - Revit returns a “Not valid file for DWG import”
Document rvtDoc = rir.Revit.ActiveDBDocument;
string path = "[PATH TO DWG/DXF]";
ElementId import = null;
using (Transaction t = new Transaction(rvtDoc, "Import DWG or DXF File"))
{
t.Start();
DWGImportOptions dwgOptions = new DWGImportOptions();
dwgOptions.Placement = ImportPlacement.Origin;
dwgOptions.Unit = ImportUnit.Foot;
View firstview = null;
using (FilteredElementCollector fec = new FilteredElementCollector(rvtDoc))
{
fec.OfClass(typeof(View));
firstview = (View)fec.FirstElement();
}
// import dxf
rvtDoc.Import(path, dwgOptions, firstview, out import);
t.Commit();
}
As you mentioned this problem is related to managing resources between booth applications.
There is a method called RhinoInside.Revit.Rhinoceros. InvokeInHostContext that should do the magic here.
It takes an Action or a Func that will run synchronously in Revit context.
This is only needed when Revit UI is involved. Other cases where this is necessary is when you need to pick elements from the Revit model.
Is there a way to store the previous transaction or commit elements so they persist in Revit, even when the Active Selection changes?
Alternatively, is there a built-in method in Rhino.Inside.Revit or the Revit API to create stable references for elements generated through Active Selection?
What I Need:
I want to preserve the previous transaction so that elements created from an earlier selection remain in Revit, even when a new selection is made. Ideally, these elements should stay in Revit until manually deleted or overridden, rather than disappearing when the selection updates.
For example, if I create a dimension based on the Active Selection (Wall), the dimension disappears when I select a new element because the reference is lost. How can we ensure references are preserved?
I am wondering if releasing the dimension into the revit document is what you are looking for? so everytime you change your selection the geometry will be created and released so when you change the active selection, it will be creating a new one and not updating the previous one… if that makes sense?
When we unpin the object, in the next selection workflow doesn’t work as the unpin element ID is stored in the component (specifically I’m talking about dimension workflow) so we have to pin it again.
So there is a difference between unpin and release element (might be what’s causing this), but let me know if the below is not the workflow you are looking for, maybe show a sample of what you are trying to achieve if it’s not?
