I just wanted to learn Revit API and create a simple wall using ExternalCommand. But I cannot figure it out...
I think my problem is here:
var symbolId = document.GetDefaultFamilyTypeId(new ElementId(BuiltInCategory.OST_Walls));
When I debug it symbolId always -1.
Can you help me what is wrong with this code snippet?
public Autodesk.Revit.UI.Result Execute(
Autodesk.Revit.UI.ExternalCommandData command_data,
ref string message,
Autodesk.Revit.DB.ElementSet elements)
{
var document = command_data.Application.ActiveUIDocument.Document;
var level_id = new ElementId(1526);
// create line
XYZ point_a = new XYZ(-10, 0, 0);
XYZ point_b = new XYZ(10, 10, 10);
Line line = Line.CreateBound(point_a, point_b);
using (var transaction = new Transaction(doc))
{
transaction.Start("create walls");
Wall wall = Wall.Create(doc, line, level_id, false);
var position = new XYZ(0, 0, 0);
var symbolId = document.GetDefaultFamilyTypeId(new ElementId(BuiltInCategory.OST_Walls));
if (symbolId == ElementId.InvalidElementId) {
transaction.RollBack();
return Result.Failed;
}
var symbol = document.GetElement(symbolId) as FamilySymbol;
var level = (Level)document.GetElement(wall.LevelId);
document.Create.NewFamilyInstance(position, symbol, wall, level, StructuralType.NonStructural);
transaction.Commit();
}
return Result.Succeeded;
}
Work through the Revit API getting started material and all will be explained. That will save you and others many further questions and answers.
To address this specific question anyway, GetDefaultFamilyTypeId presumably does not do what you expect it to for wall elements. In the GetDefaultFamilyTypeId method API documentation, it is used for structural columns, a standard loadable family hosted by individual RFA files. Walls are built-in system families and behave differently. Maybe GetDefaultFamilyTypeId only works for non-system families.
To retrieve an arbitrary (not default) wall type, use a filtered element collector to retrieve all WallType elements and pick the first one you find.
Here is a code snippet that picks the first one with a specific name, from The Building Coder discussion on Creating Face Wall and Mass Floor
:
WallType wType = new FilteredElementCollector( doc )
.OfClass( typeof( WallType ) )
.Cast<WallType>().FirstOrDefault( q
=> q.Name == "Generic - 6\" Masonry" );
Related
im working on the spatial mapping processing for my HoloLens project.
Somehow calling "SpatialSurfaceMesh::TryComputeLatestMeshAsync" keeps returning the same mesh data overtime.
Is there another process involved updating the observer?
void SpatialMapping::AddOrUpdateSurface(winrt::Windows::Perception::Spatial::SpatialCoordinateSystem const& coordinateSystem)
{
using namespace winrt::Windows::Perception::Spatial::Surfaces;
SpatialBoundingBox axisAlignedBoundingBox =
{
{ 0.f, 0.f, 0.f },
{ 50.f, 50.f, 50.f },
};
SpatialBoundingVolume bounds = SpatialBoundingVolume::FromBox(coordinateSystem, axisAlignedBoundingBox);
m_surfaceObserver.SetBoundingVolume(bounds);
m_surfaceObserver.ObservedSurfacesChanged(
winrt::Windows::Foundation::TypedEventHandler
<SpatialSurfaceObserver, winrt::Windows::Foundation::IInspectable>
({ this, &SpatialMapping::Observer_ObservedSurfacesChanged })
);
}
void SpatialMapping::Observer_ObservedSurfacesChanged(winrt::Windows::Perception::Spatial::Surfaces::SpatialSurfaceObserver const& sender
, winrt::Windows::Foundation::IInspectable const& object)
{
{
using namespace winrt::Windows::Perception::Spatial::Surfaces;
const auto mapContainingSurfaceCollection = sender.GetObservedSurfaces();
// Process surface adds and updates?.
for (const auto& pair : mapContainingSurfaceCollection)
{
auto id = pair.Key();
auto info = pair.Value();
InsertAsync(id, info);
}
}
}
Concurrency::task<void> SpatialMapping::InsertAsync(winrt::guid /*const&*/ id, winrt::Windows::Perception::Spatial::Surfaces::SpatialSurfaceInfo /*const&*/ newSurfaceInfo)
{
using namespace winrt::Windows::Perception::Spatial::Surfaces;
return concurrency::create_task([this, id, newSurfaceInfo]
{
const auto surfaceMesh = newSurfaceInfo.TryComputeLatestMeshAsync(m_maxTrianglesPerCubicMeter, m_surfaceMeshOptions).get();
std::lock_guard<std::mutex> guard(m_meshCollectionLock);
m_updatedSurfaces.emplace(id, surfaceMesh);
});
}
Generation works, Update does not
Manuel attempt same problem:
winrt::Windows::Foundation::IAsyncAction SpatialMapping::CollectSurfacesManuel()
{
const auto mapContainingSurfaceCollection = m_surfaceObserver.GetObservedSurfaces();
for (const auto& pair : mapContainingSurfaceCollection)
{
auto id = pair.Key();
auto info = pair.Value();
auto mesh{ co_await info.TryComputeLatestMeshAsync(m_maxTrianglesPerCubicMeter, m_surfaceMeshOptions) };
{
std::lock_guard<std::mutex> guard(m_meshCollectionLock);
m_updatedSurfaces.emplace(id, mesh);
}
}
}
MVCE:
Create a New Project with the template
"Holographic DirectX 11 App (UWP) C++/WinRT)"
Add the files:
https://github.com/lpnxDX/HL_MVCE_SpatialSurfaceMeshUpdateProblem.git
Replace m_main in AppView.h
We did some research and have some thoughts about your question right now, let me explain the findings
Has your Observer_ObservedSurfacesChanged method triggered exactly? Adding output statements or breakpoints can help you check it. Since SurfaceObserver should be always available, usually we need to check the availability of surfaceObserver in each frame and recreate a new one when necessary, sample code snippt please see here.
Have you set m_surfaceMeshOptions? It is not visible in the code you posted. If it is missing, you can configure it with the following statement:
surfaceMeshOptions-> IncludeVertexNormals = true;
Microsoft provided the Holographic spatial mapping sample, shows how to acquire spatial mapping data from Windows Perception in real-time. it is similar to your needs, to narrow down issue if it's an issue with your code, please try to check and run this example on your device
If after the above steps, you still can't solve the problem, could you provide an
MVCE, so that we can locate the issue or find a solution? Be careful to remove any privacy-related or other business function codes.
Your code has the following problems:
TryComputeLatestMeshAsync should be called from Observer_ObservedSurfacesChanged not from concurrency::create_task
TryComputeLatestMeshAsync return mesh with matrix, vertices and indices. Indices should be stored to a safe location at the first run, they don't change later. Vertices and matrix should copied as they returns. You shouldn't save the mesh itself, because its data updates from various threads.
ObservedSurfacesChanged shouldn't be called every frame. This is long running function.
Maybe it has something more. I would recommend to start from the sample mentioned earlier.
I am trying to change a family's part type via Revit's API after changing the family category.
I can retrieve the corresponding parameter and set its value, but (though the transaction is successfully committed) the part type is not changed.
Since the 'Part type' UI element showed an empty string, I checked via "Revit Lookup" what value the parameter had after the attempted change. It was still the old part type which doesn't even exist for that family category.
This is my code so far:
Family f = familyDocument.OwnerFamily;
Category c = f.FamilyCategory;
Parameter p = f.get_Parameter(BuiltInParameter.FAMILY_CONTENT_PART_TYPE);
f.FamilyCategoryId = new ElementId(BuiltInCategory.OST_LightingFixture);
p.Set((int) PartType.Normal);
I also tried it with two separate transactions (first one setting the category, second one setting the part type). No success there either.
Update:
Turned out, this code already worked. It was the surrounding code that created the error.
I tried the same in Revit 2018.3 and 2020.2 with success. Just create any family type (I used a lighting fixture template), and insert the following snippet into a new macro.
var f = Document.OwnerFamily;
var c = f.FamilyCategory;
var partTypeParam = f.get_Parameter(BuiltInParameter.FAMILY_CONTENT_PART_TYPE);
using(var t = new Transaction(Document, "Change part type"))
{
t.Start();
f.FamilyCategoryId = new ElementId(BuiltInCategory.OST_DuctAccessory);
partTypeParam.Set((int)PartType.Elbow);
t.Commit();
}
Compile and execute, then observe that the type is changed to duct accessory with part type elbow. Seems to work fine.
The only difference is that you seem to be in a slightly different context. You opened your family from a document context. If there is no non-obvious glitch in your implementation, this may point to an API bug. However, in my experiments this scenario posed no problems, so if there is any bug it cannot be systematic.
My aim was to change an arbitrary window family to a duct elbow. I post only the relevant parts (tested in Revit 2020.2):
internal class FamilyOption : IFamilyLoadOptions
{
bool IFamilyLoadOptions.OnFamilyFound(bool familyInUse, out bool overwriteParameterValues)
{
overwriteParameterValues = false;
return true;
}
bool IFamilyLoadOptions.OnSharedFamilyFound(Family sharedFamily, bool familyInUse, out FamilySource source, out bool overwriteParameterValues)
{
source = FamilySource.Family;
overwriteParameterValues = false;
return true;
}
}
public void PartTypeTester()
{
var f = new FilteredElementCollector(Document)
.OfClass(typeof(Family))
.First(ff => ff.Name == "ExampleFamily")
as Family;
var familyDoc = Document.EditFamily(f);
f = familyDoc.OwnerFamily;
var c = f.FamilyCategory;
var partTypeParam = f.get_Parameter(BuiltInParameter.FAMILY_CONTENT_PART_TYPE);
using(var t = new Transaction(familyDoc, "Change part type"))
{
t.Start();
f.FamilyCategoryId = new ElementId(BuiltInCategory.OST_DuctAccessory);
partTypeParam.Set((int)PartType.Elbow);
t.Commit();
}
var opt = new FamilyOption();
f = familyDoc.LoadFamily(Document, opt);
familyDoc.Close(false);
}
Works like a charm. You should not expect the resulting family to behave like a duct accessory though ;-).
I am implementing azure search in my application to provide autosuggestion feature like google, big, and amazon. I have implemented the same available github code using below URL.All is working fine but getting result in more than 1.5 second for each term of sentence.
https://github.com/Azure-Samples/search-dotnet-getting-started/tree/master/DotNetHowToAutocomplete
Currently I am using two indexes for searching and created in basic tier. Below is code
public ActionResult Suggest(bool highlights, bool fuzzy, string term)
{
InitSearch();
// Call suggest API and return results
SuggestParameters sp = new SuggestParameters()
{
UseFuzzyMatching = fuzzy,
Top = 5,
Filter="name eq 'testid'",
OrderBy=new List<string>() { "Date desc"}
};
if (highlights)
{
sp.HighlightPreTag = "<b>";
sp.HighlightPostTag = "</b>";
}
DocumentSuggestResult suggestResult = _indexClient1.Documents.Suggest(term, "index1",sp);
if (suggestResult.Results.Count<5)
{
SuggestParameters sp2 = new SuggestParameters()
{
UseFuzzyMatching = fuzzy,
Top = 5- suggestResult.Results.Count,
Filter = "Product eq 'PAAS'",
OrderBy = new List<string>() { "Count desc" }
};
if (highlights)
{
sp2.HighlightPreTag = "<b>";
sp2.HighlightPostTag = "</b>";
}
DocumentSuggestResult suggestResult2= _indexClient2.Documents.Suggest(term, "index2", sp2);
suggestResult.Results = suggestResult.Results.Union(suggestResult2.Results).Distinct().ToList();
// final = suggestResult.Results.GroupBy(s => s.Text, StringComparer.CurrentCultureIgnoreCase).ToList();
}
// Convert the suggest query results to a list that can be displayed in the client.
List<string> suggestions = suggestResult.Results.Select(x => x.Text).Distinct().ToList();
return new JsonResult
{
JsonRequestBehavior = JsonRequestBehavior.AllowGet,
Data = suggestions
};
}
To test it- when I am typing any word it's taking too much time in populating results around 1.5 to 1.8 seconds, it's working like other web app searchbox.
Timing I am checking using inspect element of chrome browser. Attaching sreenshot.see screenshot
Please suggest.
I answered a similar question on another post: Why is Azure Search taking 1400 miliiseconds to return query results for simple query
The main thing is, you shouldn't be using the Chrome timer to measure the performance of azure search. Use the "elapsed-time" field of the HTTP response you receive (take an average over multiple call), since it accurately tells you how much time was spent getting your results from azure search. The chrome timer can be affected by your network/machine configuration. If that doesn't help, you can follow the other tips I suggested in the post I linked above.
I am looking for a way to use Javascript to Query Taxonomy.js, to get a Term based on Term Name (I don't have ID available on page).
Only option that I am able to find is to retrieve all terms in the TermSet, loop through each term to match the name.
This works, but is causing performance issue. I am looking for a way to get the term directly, without looping through all.
I was finally able to cobble this together.
var context = SP.ClientContext.get_current();
var session = SP.Taxonomy.TaxonomySession.getTaxonomySession(context);
var termStore = session.getDefaultSiteCollectionTermStore();
var parentTermId = 'd89595cf-7d0d-4f19-8e14-8b8b05efb7de'; // Some parent term
var parentTerm = termStore.getTerm(parentTermId);
// arguments are termLabel, language code, defaultLabelOnly, matching option, max num results, trim unavailable
var terms = parentTerm.getTerms(series,1033,true,SP.Taxonomy.StringMatchOption.exactMatch,1,true);
context.load(terms);
context.executeQueryAsync(
function(){
//print child Terms
for(var i = 0; i < terms.get_count();i++){
var term = terms.getItemAtIndex(i);
console.log(term.get_name());
console.log(term.get_description());
}
},
function(sender,args){
console.log(args.get_message());
});
If you know one parent term's guid you can use that and then get a specific term below that. In our case the parent term only has one level of children, so I haven't checked if it searches children of children.
There is also the TermSet.getTerms() method which takes a labelMatchingInformation object as its argument. Here is the documentation and a blog about it. I couldn't get the lmi to work, but in the blog he seems to be apply it directly to a taxonomysession and I think it is supposed to be applied to a termset, so maybe that is the difference.
I'm trying to use:
var viewEngineResult = ViewEngines.Engines.FindView(ControllerContext, myViewName, null);
as part of a process to render the contents of a view to send nice formatted emails. I'm using it inside an Orchard Controller. I have used similar code outside of Orchard in an MVC project and it works fine.
However in Orchard running this code fails to find the view I'm looking for and returns a view engine result that has searched 0 locations.
viewEngineResult has the following values after it is called:
SearchedLocations: Count = 0,
View: null,
ViewEngine: null
Is there a reason this doesn't work in Orchard and is there a way to make it work?
This answer is based on the advise given me by Bertrand, but I wanted to bring it together with what I'd discovered.
To be able to use FindPartialView I needed to inject an instance of IViewEngineProvider into my controller.
I then used the following code to resolve and render a view:
private String RenderView(String viewName, object model)
{
var paths = new List<string>(); // This can just be an empty list and it still finds it.
var viewEngine = _viewEngineProvider.CreateModulesViewEngine(new CreateModulesViewEngineParams {VirtualPaths = paths});
var viewResult = viewEngine.FindPartialView(ControllerContext, viewName, false);
if (viewResult.View == null) {
throw new Exception("Couldn't find view " + viewName);
}
var viewData = new ViewDataDictionary {Model = model};
using (var sw = new StringWriter())
{
var viewContext = new ViewContext(ControllerContext, viewResult.View, viewData, TempData, sw);
viewResult.View.Render(viewContext, sw);
return sw.GetStringBuilder().ToString();
}
}
I think you'll want to take a close look at Orchard.Framework/Mvc/ViewEngines, in particular IViewEngineProvider and ThemeAwareViewEngine. There's a lot more going on when in Orchard, such as themes, multi-tenancy, and a richer environment in general that may be needed to make this work.
What's likely happening here is that the view engines don't have enough information to resolve a view and thus opt out of the chain. You might want to put a breakpoint into ThemeAwareViewEngine.FindView, and then inspect the private dependency fields of that class. I wouldn't be surprised if they were null, because getting to FindView through statics will probably not allow dependency injection to do its stuff properly.
Then again I'm just guessing.