Hi
There doesn’t seem to be a way to use OOTB nodes to create a multi-category schedule. The closest category from the select category node is multi-category tags which isn’t correct.
I know there is a Python solution it would be useful if the OOTB nodes could do it.
What would you expect to feed it in order to get a multi-category schedule? A null value could also be an error that you wouldn’t want to pass on as a valid input. No input is reserved for returning a function. Potentially it could be a default value, but I’m not aware of any nodes with default input values that can’t also be provided explicitly.
It would probably be pretty easy to create a brand new node with no category input for multi-category schedules, but I don’t know if that’s always reason enough (if we’re talking new nodes in general). There are plenty of use cases without nodes - many would likely be simple enough to add - but there’s a huge issue of diminishing returns when the entire API is available in Python.
I’m certainly not saying that it’s not worth pointing out these cases or expanding the Dynamo node library. But I am saying that it’s a good excuse to learn Python and the API. 
Perhaps one new node to return an invalid Element ID, which I think is the input which method’s expecting to create the multi-category schedule…
Originally that was going to be my suggestion, but I don’t know how helpful it actually is. That would mean the node takes Categories and one specific ElementId. It would be nice if Revit had an actual Category for the InvalidElementId but beyond that I feel like it gets confusing mixing the objects. The CreateSchedule node would still have to change though, as I don’t think you can just feed it an InvalidElementId currently.
I do think this is a good idea in general though. There are other use cases that require the InvalidElementId.
I am likely overlooking something, but offhand my thought was that starting with Dynamo for Revit 3.x we add a new object type for invalid element id, which inherits the category class (for now), so that if you provide this invalid element into a node which can take an invalid element Id in place of a category, it will pass that argument and run the node.
It’s a BIG change but it could have a LOT of use, as inputs for other nodes by expanding the inheritance to other data types (i.e. the material inout of the FamilyType.ByGeometry node) could also potentially make use of this data type… however it could also break a lot more than it fixes, so any change needs to be made carefully.
@Paul_Wintour hopefully you can make due with the current Python or your own custom node for now, as this can’t happen fast and introducing a larger change such as a new data type midway through the community’s transition to Dynamo 3.0 seems like it might be problematic.
FYI @emrullah.yildiz
Yeah, this is exactly what I had in mind. It would be even more helpful if it could be expanded to other classes as well. (Element and ElementId are the two that I can think of off hand that I believe also have some cases of arguments that can take the InvalidElementId as an option.)
Yes there is a Python solution and it works fine and will do for now. But I do think there should be an OOTB solution.
If you consider the manual way of creating a schedule, multi-category is the default option. Now, as I understand it, technically multi-category is an invalid element and not a OST category. So things are already confusing as multi-category is listed under category in the popup window.
Personally, I would make the default category input multi-category unless another category is supplied. Yes this will probably mean updating the code of ScheduleView.CreateSchedule.
I’m not sure what other functions/nodes would need multi-category. I can’t think of any at the moment. But if there was, you could always add in multi-category as the first item in the select categories component. The problem of course would come when someone uses this defaulty value in a node which doesn’t accept/use multi-category. So there is no simple solution as far as I can see.
I think one of the solutions could be add the multicategory option under Categories node and when it s selected it should do what Python is doing -a special case for categories node. An additional node for the Element.InvalidId would be also very useful when needed; but I cannot remember any node that requires a categoryId. I cannot imagine when it would be needed.
This is another example of the way the program presents itself being vastly different from the way the program works. Similar to drawing a circle as a filled region, the way things look in the UI (accepting a sketch with one element in the curve loop) isn’t valid when coding. Being faithful to the spirit of the internal workings should be a guiding principal in what we do as it makes users transitioning to textural scripting, developing code, and building apps. Yes it is easier to bowl with bumpers but it’s less fun and being ‘good with bumpers’ don’t really mean you’re good at bowling. IMO we have enough guardrails already, but users need to be able to do everything we need to do so there is a gap for sure.
The problems with adding a category which doesn’t exist to a dropdown are many.
Adding a non-category to the categories list adds to user confusion. ‘All elements of category’ won’t like multi-category, and localized it will get quite odd in terms of ‘why doesn’t this work’. FamilyType won’t either, and that might make sense to some users. The only thing where ‘multi category’ exists which I can think of is schedules, and that is using the invalid ElementId (element ID -1 for reference) in the call. That same invalid ID can be used to assign a material to ‘by object style’. Or use the default floor/wall/ceiling type. Or do a whole bunch of stuff. We just have to tell the nodes to accept that as an input (step 1), and enable it as the default input (step 2) for some nodes going forward.
The technical stuff can always be made to work, but it is by design that the dropdowns are populated via the enumerations in Revit - that is we see things which the application provides so if you open the same graph in 10 versions of Revit (Dynamo is old now!) we would only see stuff which Revit tells Dynamo about. This is also why we usually can’t select ‘nothing’ after making a selection.
All of this is to say ‘we need a way’, but I think if we do this with some care and consideration we can enable this feature and a lot more.
