Today, let's look at two Japanese Forge questions, on model groups and the Revit engine language, another RevitLookup enhancement, and, while we're talking about languages, a surprising scientific discovery on naked mole-rat dialects:
ScheduleDefinition GetFieldLet's start with the query 8473 – question about model group for Forge:
Question: I have a question about Revit model groups.
Is it possible to get the group information in Forge?
For example, if I select Group 1 in the UI, I would like to select all the objects in it, determine the group name and other information about group member elements.
So, does the Forge viewer support selecting a Revit model group? Is there any way to retrieve the model group information in Forge, or is it 'lost in translation'?
Answer: The viewer doesn't support it out of the box, but the information is still preserved in the Forge translation of the RVT model, not lost in translation.
You can navigate Groups and their Members by descending down the non-graphical property hierarchy, starting at the root/model element. Then, it is also possible to programmatically simulate group selection by selecting group members.
Here is an example of a group (ID=50) with one member (ID=389), which is a chair element in the Revit sample project rac_basic_sample_project.rvt:
The StackOverflow discussion on grouping elements cannot find in Forge viewer shows a pretty neat code snippet by Eason Kang implementing this functionality.
Many thanks to Traian Stanev and Eason for their valuable help in addressing this.
The next Japanese Forge issue is 8492 – language settings of DA4R engine:
Question: I have a question about DA4R, Design Automation for Revit.
Can I specify the language of the Engine of DR4R? I would like to use the Japanese Engine – is the default engine English? My add-in seems to depend on the Japanese Engine.
Answer: Good programming practice would ensure that the add-in is not language dependent.
Since every DA4R add-in is a DB-only application, it should in theory be language independent automatically.
Unfortunately, Revit itself does not completely follow this practice in all points.
Furthermore, every Revit BIM relies on many component that can be modified and added by end users, e.g., family definitions, which are pretty hard to make language independent.
So, I understand your challenge.
As a first step, let's look at the situation in the desktop Revit API and search the Revit API discussion forum for the term 'language'; that turns up two useful entries:
The Revit API provides
the Application.Language property to
determine the language used in the current session of Revit, so that part is easy.
However, the API does not provide any method to control the language being used.
On the desktop, you can use the language switch in the Revit.exe command line, cf. the discussions on Revit command-line switches and multiple language RESX resource files
Now, trying to apply this insight to the DA4R environment, there are two questions:
I believe the answer to both of these is yes.
Searching for 'commandline' and 'revitcoreconsole' turns up an example of passing in a command line argument to the DA4R engine.
And yes, indeed, the same language command line switch works with an optional /l argument to revitcoreconsole.exe.
It is described in more detail with a sample code snippet in the official documentation on publishing an activity.
Response: I tried the /l option, and then my add-in completed the process with no error:
revitcoreconsole.exe /l JPN (arguments...)
Thanks much for your support and information!
Thanks also to Rahul Bhobe for helpful advice.
Following up on his enhancement
enabling RevitLookup to handle split region offsets last
week, Michael @RevitArkitek Coffey submitted a
new issue #70 – ScheduleDefinition.GetField method not showing and
the subsequent pull request #71 adds handler for GetSplitRegionOffsets, saying:
The method
ScheduleDefinition.GetFielddoes not show because it requires an integer index parameter. A list of ScheduleFields can be returned, named by the index that was used.I have this working and can submit a pull request. I have an issue though, in that there are two
GetFieldmethods, the other taking in an id. I have not found a way to filter out the second method, so when viewing theScheduleDefinitionproperties there will be twoGetFieldentries. If you know of a way to filter out that second method you can let me know or you could add it. Otherwise, it could be left as is or put on hold.
Answer: That sounds great, very useful!
Thank you very much for the offer!
That would require analysing the complete GetField method signature.
The two overloads GetField(Int32) and GetField(ScheduleFieldId) have
different method signatures.
They can be distinguished using by checking their parameter types using .NET Reflection, as explained
in how to get only methods with a specific signature out of Type.GetMethods.
The new functionality is captured in RevitLookup release 2021.0.0.13.
A surprising scientific analysis of their vocalisations demonstrates that naked mole-rats speak in community dialects:
Sharing a dialect strengthens cohesiveness in the colony
... helps with group solidarity and connection
In any social group, including our own, having a rapid way of identifying who belongs to the group and who is excluded is useful for many practical reasons.
For something not related to programming or science, let's take a moment to simply savour this beautifully crafted and implemented stitched-together van Gogh 360: