Revit_oM? : Revit Built-in Categories as Enum

[travispotterBH]

trafficstars

Description:

Per conversation with @pawelbaran it could be helpful for new users into the BHoM to be able to select the Revit category they wish to pull by a dropdown instead of typing. I imagine this as an enum.

Not sure where best this would live though given that it is a UI specific category list, though it would be helpful in both Excel and Grasshopper pull from Revit workflows.

[al-fisher]

This looks really good. 👍

Not sure where best this would live though

Would suggest this is indeed in a Revit_oM - but developed over in the Revit_Toolkit repo @travispotterBH - you can even transfer this issue over

[pawelbaran]

Yeah I support the idea, also a follow up from another discussion: adding two new properties to FilterByCategoryRequest:

• bool Elements { get; set; } = true;
• bool Types { get; set; } = false;

This would default to pull elements only (what users usually want), but would allow pulling types (only or combined with elements) as well.

[pawelbaran]

Related to https://github.com/BHoM/Revit_Toolkit/issues/644

[pawelbaran]

Oke, after a long investigation we have the following conclusions:

• Revit category labels contain duplicates, which means we cannot fully depend on filtering by label - on the other hand, so far no relevant category with duplicate label has been identified (by relevant I mean the ones usually pulled by the users)
• afaik we cannot represent enums as human readable text in the UI

So what I would suggest is adding the following enum to Revit_oM:

[UseDescriptionsAsLabels]
public enum Category
{
	[Description("Walls")]
	[DisplayText("Walls")]
	OST_Walls = -2000011,
	[Description("Floors")]
	[DisplayText("Floors")]
	OST_Floors = -2000032
}

...where UseDescriptionsAsLabels attribute would indicate that the description would be shown as the label of a dropdown item, DisplayText showing as value:

Alternatively (possibly even neater):

public enum Category
{
	[DisplayText("Walls", true, true)]
	OST_Walls = -2000011,
	[DisplayText("Floors", true, true)]
	OST_Floors = -2000032
}

...where the bool parameters of DisplayTextAttribute would indicate whether it should be used as label of the dropdown item (what we need) or the output string (what it actually does).

Once we have the above enum in place, the workflow is as follows:

• in GH the user can use either a hand-typed string or the enum that gets converted to the relevant label string
• the label string gets matched against the BH.oM.Revit.Category enum based on the DisplayTextAttribute
• BH.oM.Revit.Category enum value gets matched against Autodesk.Revit.DB.BuiltInCategory based on the int representation (needs to always match)

The above workflow brings 2 main benefits:

• lets us break out of the Document.Settings.Categories closed collection - we can add any values to our enum and they will be correctly matched, e.g. your Revision should work @travispotterBH
• thanks to the fact that we can use any value with any label, we can manage duplicates by setting more detailed labels to them compared to Revit (e.g. Lines occurs at least twice, for model and analytical lines, probs for sketch etc. too - in this case we will be able to add the values as Model Lines, Analytical Labels etc., while still matching via int value)
• what is more fun, based on the above we should be able to label and support even the categories that miss labels in Revit itself 😃

The only drawback of this solution would be that the enum needs to be created (semi)manually - ofc I have a method generating the formatted items for me, but this I would only run for the initial set of items. From then, we will need to add every category explicitly (which on the other hand may be a good thing taken there is over 1000 built in categories in Revit, we probably do not want to expose most of them to the users).

Thoughts?

[FraserGreenroyd]

@pawelbaran we have a DisplayTextAttribute in the oM which @adecler added specifically for being able to give human-readable names to enum values, but it doesn't take in any extra bools?

[pawelbaran]

That's right @FraserGreenroyd, and this is exactly what we are missing to build the whole setup. So my idea is to introduce the 2 bool parameters to the attribute in order to achieve the required behaviour (label and value as human readable text, not only value). Also as discussed with @IsakNaslundBh, the current attribute is pretty confusing as both of us would expect the label to be human readable, not the value. So I think it would be a good move both to clarify as well as extend the feature. Thoughts?

[FraserGreenroyd]

Ah ok, I'm not sure what's been discussed with @IsakNaslundBh - I thought this was just a UI update needed but I could be wrong so happy to let the two of you work it out on what updates are needed and we can resource that together for changes needed up/down the chain 😄

[adecler]

To summarise the chat I just had with @pawel:

• The DisplayTextAttribute is purely there to compensate for the limitations of C# regarding spaces and special characters. As such the single string parameter that it takes fulfills the brief. If an enum can already be spelled correctly within the limitations of C#, than the attribute is not needed. With that logic, the attribute fits well within the responsibility, capability and understanding of someone working on the oM and is not related to any UI management.
• Any decision on how an enum is displayed in the UI should be made by that UI and not by each individual enums. The oM should not have to take the responsibility of UI behaviour. So those 2 booleans are not making sens to me.
• I also don't see why each enum should be treated differently in the UI. So, until we have a clear case for this, I would solve any display management of enums in the UI itself and treat all enums equally.

[pawelbaran]

I think I have clarity now. Happy to keep DisplayTextAttribute as is and align BHoM_UI to pick it while generating dropdown labels - it serves my purpose while keeping things simple. The discussed enum will then look as follows:

public enum Category
{
	[DisplayText("Walls")]
	OST_Walls = -2000011,
	[DisplayText("Floors")]
	OST_Floors = -2000032
}

Thanks all for the good discussion 👍