A whole bunch of exciting stuff going on:
SetReferencesWallType naming best practicesAU 2022 introduced Forma for AEC. Now, its vision is explained further by the Forma sustainability flyer:
Design a Better Future with Forma’s Suite of Sustainability Solutions:
Cities consume more than two-thirds of the world’s energy and account for over 70% of global carbon emissions (source). This means architects, real estate developers, and urban planners have an exceptional opportunity to mitigate the environmental impact of our cities by designing buildings and communities with sustainable outcomes in mind.
Sustainable outcomes are best achieved through a proactive, data-driven approach that starts at the earliest stages of design before it becomes costly and difficult to make changes. Autodesk Forma’s powerful suite of real-time analyses equips design teams with the quick, visual insights needed to prioritize sustainability from day one of a project.
RevitLookup 2024.0.6 has been released, bringing a wealth of new and enhanced functionality:
ElementId to Category, whenever applicable. This simplifies navigation and enhances the user experienceWe still need to discuss which options should be enabled by default; so, please share your feedback on the new release in the RevitLookup GitHub repository.
The new release has 10 assets and thus supports previous releases of Revit all the way back to Revit 2021:
Visit the release page to download them.
A nice explanation and succinct solution by Richard RPThomas108 Thomas and Jonas Hoyer on view's workset editable – change from No to Yes with the API?:
Question: Can anyone tell me if it's possible to change a view's workset status from "No" to "Yes" (editable) using the Revit API (Revit 2023 or earlier), in this form:
I searched the Internet and found several similar posts saying it wasn't possible, but they were for much older versions of Revit. Thanks in advance!
Explanation: When you take ownership of a workset, it becomes editable to that user 'Yes'; when you relinquish the workset it reverts to 'No' (which doesn't actually mean you can't edit it).
WorksharingUtils CheckoutWorksets allows the user to take ownership of the workset and make them editable to that user.
RelinquishOwnership allows user to decide via RelinquishOptions what is relinquished (given back) including various workset types.
I believe the 'editable' indicator is just a function of if the current user has taken ownership of a certain workset or not, i.e., they can take ownership of a workset for whatever time period to be sole editor of it until they relinquish it. The 'Yes/No' is only meaningful when you are the owner of it. The interface is probably outdated and contains bad terminology to a certain extent. The default is 'No (Non Editable)' meaning everyone can edit items on a workset via borrowing elements (so 'non editable' means you can edit it and so can everyone else).
I believe the only other time it is 'yes' is when you've just created a workset but are yet to synchronise it to central. You can't make it 'non editable' available to all users until after you've synchronised it (because it doesn't yet exist in the central file). So, under that circumstance, you would have to synchronise then relinquish. Similarly, if you wanted to rename a workset you would have to make it 'editable' first.
So, in summary, the 'Editable/Non Editable' aspect should be read as relating to if current user can solely edit the workset or not rather than just being a borrower of elements on a workset.
The 'Owner' column exists separately from the 'Yes/No' one because some types of workset you decide to be the editor/owner of (user created ones) whereas when you create a view the ownership of the view workset is inherently you until synchronised.
Have you tried the WorsharingUtils class for the View worksets in question?
Under certain circumstances described above you will not be able to influence this 'editable/non editable' aspect via the API for a single user because it is related to how two or more people are interacting in a workshared environment, e.g., if someone else owns the workset then you can only ask they relinquish it.
Choosing to take ownership of entire worksets is generally the old way of working before element borrowing was used. Mostly, people take ownership just to do infrequent things such as change workset names but that isn't applicable to View worksets. They may also take ownership to restrict access but again not for views.
Solution: To set the editable status of the view workset to yes you have to check out the workset of the view by using
the CheckoutWorksets method
of the WorksharingUtils class.
You can retrieve the WorksetId of the view with the ELEM_PARTITION_PARAM BuiltInParameter.
Then, you can construct a WorksetId with the returned integer and use that to checkout the view's workset.
That will set the editable status to yes.
Hope this helps!
Many thanks to Richard and Jonas for the explanation and solution!
Since we have not mentioned it before, here is a quick heads-up to a relatively new API method enabling sub-element highlighting:
Question: After retrieving an element in a linked file via PickObjects with a 'LinkedElement' 'ObjectType', how can I highlight the linked element selected in the current view to achieve the effect of using the TAB key to select the linked element in the UI?
Answer: Since Revit 2023, you can use the Selection SetReferences method to highlight the references passed in to it.
A reference can be an element or a subelement in the host or a linked document.
Question: How about previous releases of Revit?
Answer: In Revit pre-2023, you only have SetElementIds. That only enables you to select top-level elements in the host document. I am not aware of any other way to select an element from another document in pre-2023 Revit.
A discussion on best practices naming WallType elements in the thread
asking is it possible to change the WallType name through API?
Question: I am thinking in develop a script that changes all walls' types' names based on properties of the wall types.
I sometimes see a name of the type that mentions 30cm Thickness and does not match the real thickness of the wall type, so my script should generate the wall type name based on the function (exterior, interior , etc.), the material of each layer of the wall and thickness and the total wall thickness.
For example, InteriorWall_Concrete-100 for a one layer interior wall and 100mm thickness, or, more complex,
ExteriorWall_Concrete-100_Bricks-100_200Is that against best practices?
That plugin would avoid having different naming systems and ensure that the name of the type matches the real properties... sounds a crazy thing for you? or super complicated task?
Answer 1: For me, as a programmer, that makes perfect sense and is perfectly feasible. However, I am not a BIM expert and cannot advise you on best practices. I would suggest that you also raise that question in the generic architectural forum.
Answer 2: I might be able to add a bit of info for you; my primary job is Revit tech (and support) in an Architectural firm (I just do a little coding when needed to get things working the way we need them to) and I have worked as CAD/BIM Manager at a couple of firms over the many years and I can confirm:
That is an excellent idea and will greatly benefit those working in the model(s).
Answer 3: This is one of the fundamental things we all want to do at some point: reduce what a type is to a string value of the main things that define it. The idea works fine until there is a certain minor detail which distinguishes two types. In the end, human beings use Revit models not robots. So, there is only a certain extent to which you can codify such things and it still be readable and fit on screen where it is read. What features are most important to represent and in which order, that is always the endless discussion.