If I remember correctly we did discuss the other way (from CommandData to ToolData) quite a while ago (see https://plugincafe.maxon.net/topic/10044/13513_using-objectmessage). But I guess using this same technique could still be applicable to your current request.

Most important is to understand that a CoreMessage is not captured by a ToolData. This type of message can only be captured by a MessageData plugin, where you then could "translate" it into a message that actually is sent to the ToolData.

What I have been successful in using is, performing following from the "transmitter":

BasePlugin* tool = FindPlugin(TOOL_PLUGIN_ID, PLUGINTYPE::TOOL);
if (tool)
	tool->Message(TOOL_MSG_PREPAREDATA);

Where TOOL_PLUGIN_ID is the plugin ID of the ToolData, and TOOL_MSG_PREPAREDATA is a custom defined message, using a unique plugin ID.

And then using following in the "receiver" ToolData:

Bool MyToolData::Message(BaseDocument *doc, BaseContainer &data, Int32 type, void *t_data)
{
	if (type == TOOL_MSG_PREPAREDATA)
	{
		PrepareData();
	}

	return DescriptionToolData::Message(doc, data, type, t_data);
}

You cannot assign shortcuts to buttons.
An alternative solution (which I have used in the past) is to create a CommandData plugin for each button, and let the CommandData::Execute call the button. Or instead of a CommandData plugin you could also create a separate script for each button.
Either way, these can then be assigned a shortcut.

@bentraje said in Bug on GetActiveObjects() on R20.057?:

objSel = doc.GetActiveObjects(c4d.GETACTIVEOBJECTFLAGS_SELECTIONORDER)
print objSel[0]
print objSel[1]

Works fine by me.

I have a cube and a plane primitive. With the two selected, I get a printout for both. No out of range.
Running 20.057 (on Windows).

<c4d.BaseObject object called 'Plane/Plane' with ID 5168 at 0x0000004C44847570>
<c4d.BaseObject object called 'Cube/Cube' with ID 5159 at 0x0000004C448476D0>

When I only select a single object then I get an out of range (obviously):

IndexError: list index out of range

EDIT:
Hang on, when I make one the child of the other and have both selected, I do get an out of range.
But this is obvious, since your active objects flag doesn't mention children. As such, you do only have a single parent object selected.

To take children into account as being detected as selected, you need:

 objSel = doc.GetActiveObjects(c4d.GETACTIVEOBJECTFLAGS_SELECTIONORDER | c4d.GETACTIVEOBJECTFLAGS_CHILDREN )

import c4d

def main():
    c4d.gui.ActiveObjectManager_SetObject(c4d.ACTIVEOBJECTMODE_OBJECT, op, 0, c4d.ACTIVEOBJECTMANAGER_SETOBJECTS_OPEN)

if __name__=='__main__':
    main()

spam frenzy all over again, lately.

I have been in need of something similar as well. And if I remember correctly it has been discussed a few years ago.
Reason is that a ToolData or DescriptionToolData might need to initialize some stuff depending the currently active object. When the user selects a different object in the ObjectManager, the ToolData might need to reinitialize some stuff.

The solution proposed in the past was to use a MessageData and listen to EVMSG_CHANGE to check if a different object has been selected using the object's "unique" id and then trigger the ToolData by sending a SpecialEvent ... or something.

It is quite a complex implementation that seems to work, but probably is very error prone.
I wish we would have had some kind of message telling the active object selection was changed (from inside the ToolData), not via-via. And definitely not using such a hacky and complex solution.
It has been a while, but I seem to remember that the whole use of the object's unique id was rather flawed as the id didn't exactly seem to be that unique after all.

Anyway, I am still hoping for a nice solution to detect when user changes the current active object. But it seems to not be possible after all.

I am less active since a few months, and this will probably not change any time soon, but let that not restrict me for sending Best Wishes for 2021 to everyone of the SDK team.
Not only to those more present and visible in the forums, but also to those behind the scenes that keep everything running.

Thank you for your 2020 support and best wishes for 2021.

You need to obtain the tool's data in order to be able to modify/set it.
The callcommand just activates the tool.

import c4d

def main():

    # activate the command
    c4d.CallCommand(1019952)

    # change its settings
    nTool = c4d.plugins.GetToolData(doc, 1019952)
    nTool[c4d.ID_CA_JOINT_NAMING_REPLACE] = "_L_"
    nTool[c4d.ID_CA_JOINT_NAMING_REPLACE_WITH] = "_R_"

# Execute main()
if __name__=='__main__':
    main()

In the above code "nTool" is a BaseContainer, that won't work.

I also found the following in the legacy forum

import c4d

def main():
    
    toolID = 1019952
    c4d.CallCommand(toolID) 

    tool=c4d.plugins.FindPlugin(toolID, c4d.PLUGINTYPE_TOOL)  
    tool[c4d.ID_CA_JOINT_NAMING_REPLACE] = "_L_" 
    tool[c4d.ID_CA_JOINT_NAMING_REPLACE_WITH]= "_R_"
    c4d.CallButton(tool, c4d.ID_CA_JOINT_NAMING_REPLACE_APPLY)  
    
    c4d.EventAdd()

Another take on modifying the settings, since the "tool" returned from FindPlugin is a BasePlugin which is derived from BaseList2D, exactly what we need for the CallButton

The geometry of an object is stored in hidden tags (points and polygons, namely)
These are not visible, nor selectable ... and thus can theoretically not be deleted by user. But you still can access these via Python, or C++. As such, when removing all tags you also remove critical ones, that are needed by the object in order to exist.

If I remember correctly, most strings now need to be of type maxon::String. Can't remember in which version this was introduced (and that doesn't really matter).
Since then you could be using suffix _s
GePrint("Print this string..."_s);

There are different ways to output to the console, but I am now mainly using ApplicationOutput.

Wasn't this listed in one of the "API Changes in Rxx"?

For a start some of the methods of CommandData have received an additional argument GeDialog *parentManager.

Apart from that I would suggest to just setup an R21 (and up) environment(s), port your project files to these, and start building the plugins.
From the errors you encounter you might find out what needs to be changed.

I know, this sounds quite a lot as "trial and error", but that's the only advice I have right now.
Unless you want to dig through all the SDK documentation's "API changes in R21, S22, R23, S24, R25, S26"

Once you have adapted your source files for macOS, you will be able to just take these over in your Windows (updated) projects, and build the plugins for PC.

EDIT:
I myself had set up on Windows an "SDK_Rxx" folder per release, and had extracted the SDK into these, together with the specific projecttool per release.
Same for macOS, but there I had prepared an external SSD with different OS versions, and XCode installs.
(example: Sierra -> R20 + XCode 9, High Sierra -> R21 + XCode 10, Mojave -> R23 + R25 + XCode 11)

No worries.
From your reply it seems this is a bug that is being tackled in a future release.
I don't mind this being fixed, but was hoping for another solution (or workaround) to be available for current and older versions (I am still on R20).

However, if using the MouseInput is the only way to go for detectig CTRL+RMB (with known limitations) then I guess we can close this topic.
Thank you for your time.

Thanks for the link to the updated page on the dev blog.

Can we please get an update on:
https://developers.maxon.net/docs/Cinema4DCPPSDK/html/page_maxonapi_dev_windows.html

As I still am mainly in "R20-timezone" I was trying to figure out which versions of Visual Studio are to be used to compile plugins for R23 and R25.
(Might be useful to also update the macOS page ... if needed)

Thanks.

@m_magalhaes said in Detect CTRL + RightMouseButton in SceneHook:

popup is not allowed for the tool

I didn't think of that one.
This does seems to mean that using SceneHook::MouseInput to detect CTRL+RMB is probably not the right approach.

Is there another way to detect this action, no matter what tool is active?

@m_magalhaes said in Detect CTRL + RightMouseButton in SceneHook:

In fact, scenehook with a priority lower than 2000 will not be called if you are using another tool than move, scale or rotation.

That might be the case for ToolData derived tools, but I can confirm that with a DescriptionToolData derived tool active the scenehook (with priority 1000) does get called.

By default pressing the RightMouseButton in an editor view will show a popup menu. I would want to be able to trigger something similar, but without removing the possibility to trigger the default popup menu with RMB.
For this reason I came up with the combination of CTRL + RMB, which I detect in my SceneHook::MouseInput (as follows):

if (msg.GetInt32(BFM_INPUT_CHANNEL) == BFM_INPUT_MOUSERIGHT)
{
	BaseContainer keyChannels;
	if (GetInputEvent(BFM_INPUT_KEYBOARD, keyChannels))
	{
		Bool ctrlModifier = (keyChannels.GetInt32(BFM_INPUT_QUALIFIER) & QCTRL) != 0;
		if (ctrlModifier)
		{
			ApplicationOutput("SceneHook - MouseInput: RMB + CTRL was pressed");
			return true;
		}
	}
}

This is working fine when a move, rotate, scale tool is active. Even when an own custom created DescriptionTool plugin is active.

However, when the Live Selection tool is active, the code is not triggered.
At least not with the default "EXECUTIONPRIORITY_INITIAL" (=value 1000) I had provided when registering my scenehook plugin.
When I provide "EXECUTIONPRIORITY_ANIMATION (=value 2000) only then does the code get triggered, also when Live Selection tool is active.

return RegisterSceneHookPlugin(MY_SCENEHOOK_PLUGIN_ID, GeLoadString(IDS_MY_SCENEHOOK), 0, MySceneHook::Alloc, EXECUTIONPRIORITY_ANIMATION, 0);

Any value below 2000 just ignores to trigger the code when Live Selection tool is active.
Now, I can understand this is probably not a bug, but made on purpose. But why?
Why would the Live Selection tool have more "priority" then any other tool?

Note:
I am prototyping this with R20 (on Windows). Have not yet tested with later versions. Nor tried on macOS.

I didn't follow this topic in detail when it was originally posted, but I now noticed that in several of my plugins I do also use
GetInputState(BFM_INPUT_KEYBOARD, BFM_INPUT_CHANNEL, KB);
in order to check for possible qualifiers being pressed.

I guess this must have been picked up in the old forum, as the code is quite some years old.
It may not have been the intended way, but it seems to have been working all those years. At least till R21, as I haven't worked on more recent versions.

In the old forums there were quite some pieces of "example" code scattered around in posts, and back then it was a way to find out how to use some of the available functionality, due to limited documentation.

Speaking of documentation:
I just noticed that https://developers.maxon.net/docs/Cinema4DCPPSDK/html/class_scene_hook_data.html
lists MouseInput and KeyboardInput both pointing to "Input Events" for their last function argument
[in] msg The keyboard message container. See Input Events.
But the link just points back to the beginning of the page.
Where to find more details about these "Input Events" ???

1. It depends where you want to know the tag was disabled? It also depends if you want to get triggered by the tag being enabled/disabled, or simply wants to check at given time if tag is enabled/disabled?

If you want to know from within the TagData-derived object the enable state of the tag you can (with a method receiving a GeListNode* node as argument) do:

BaseTag* tag = (BaseTag*)node;

Bool enabled = false;
if (tag)
{
	GeData d;
	tag->GetParameter(<your tag's ENABLE-id>, d, DESCFLAGS_GET::NONE);
	enabled = d.GetBool();
}
...

If you want to get triggered by the change of state then:

Bool YourTagDataDerivedClass::Message(GeListNode* node, Int32 type, void* data)
{
	if (type == MSG_DESCRIPTION_POSTSETPARAMETER)
	{
		DescriptionPostSetValue* postsetval = static_cast<DescriptionPostSetValue*>(data);
		if (postsetval && (*postsetval->descid == DescID(<your tag's ENABLE-id>)))

... and same as above: you get the state of the enable-parameter

• or -

Bool YourTagDataDerivedClass::SetDParameter(GeListNode* node, const DescID& id, const GeData& t_data, DESCFLAGS_SET& flags)
{
	if (!node)
		return false;

	const Int32& gadgetID = id[0].id;
	switch (gadgetID)
	{
		case <your tag's ENABLE-id>:
			enabled = t_data.GetBool();

2. I guess the button in front of the "Enable" label is the keyframe button, so you can animate the tag being enabled/disabled over time.