How to get selected DescId and BaseList2D at the same time

ECHekman

I found the way to get the selected DescID from the Attributes viewer (DescriptionCustomGui).
However when viewing nested NodeDatas it is not clear to which NodeData the DescID belongs.
For example Instance Object has a "Reference Object". Basically a linkbox. When you open it, you can select attributes in there, however it is then not clear to which NodeData this DescID belongs to: the Referenced Object, or the Instance Object itself.

BaseContainer selection;
RTViewer->GetDescIDSelection(selection);
if (auto data = selection.GetIndexData(0))
{
    DescID* desc = reinterpret_cast<DescID*>(data->GetCustomDataTypeI(CUSTOMDATATYPE_DESCID));
    // How to know which NodeData object this belongs to?
}

ferdinand

Hey @ECHekman,

well, when a node displays an embedded description (what you exemplify at the case of a BaseLink), it uses a DescriptionCustomGui too. Other parameter types aside from a BaseLink which can do this are for example field lists.

I am quite frankly a bit surprised that this even bubbles up in the form you report it, that you get a DescID which is selected inside a DescriptionCustomGui that is shown by the node in the DescriptionCustomGui you opened yourself. Attribute Manger selection states (and by extension DescriptionCustomGui) are not a public API feature, as we usually keep our GUIs sealed, i.e., inaccessible to third parties. DescriptionCustomGui is here a bit in a grey area, but I am afraid there is no way to do what you want to do. To do what you want to do, you would need access to internal systems.

And other than in some other cases, where we do not always had the time to expose something (and are open to the idea of changing something), this is for GUIs not the case; they are intentionally sealed as we do not want third parties to change basic UX concepts.

My general advice would also be to not to try to overcome this boundary (that a plugin reacts to which parameter in a node is being highlighted by the user), as you break UX conventions of Cinema 4D with that.

Cheers,
Ferdinand

You can do this, but it is very hacky:

Get the description of the node(s) you are currently displaying in the your DescriptionCustomGui.
Check if desc is a member via CheckDescID (I think GetParameter would also work and return an empty container when the ID does not exist).
When the ID does not exist, start browsing the container for parameters that are of a DTYPE that implies an underlying node, such as DTYPE_BASELINK.
When you find such parameter, get the node node, and check there.
Rinse and repeat recursively.

Issues:

You cannot distinguish the case where an object A has two BaseLink parameters which both hold an object of type T, but not the same instances.
You will run into issues with DescID translations which some nodes might do. This is a really big point, which is probably already overlooked in your current code.
Nested node relations can get REALLY complicated. BaseLink is trivial, but stuff like field lists, volume lists, or some special shader stuff can get really complicated. You would probably only have to worry about base links and field lists in your case, as other renderers are irrelevant for you, but field list alone are already complex enough that I would strongly advise against 'just implementing it'.