@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 )

@r_gigante
Yes indeed, the question is more theoretical than technical. That is the reason I originally posted it in the section "Forum information & resources", as it was more intended to try and agree on a naming convention to be used in the forums.
I don't mind seeing the topic moved to the development section instead.

From a user/customer point of view the whole set of new functionalities is considered a "plugin".
Internally, however, it can consist of many "plugins" (scenehook, nodedata, message, ...).
Which is confusing to explain in written. When does "plugin" mean the latter, when does it mean the former?
For instance, the SDK documentation has a page dedicated to Plugin Types. Here "plugin" is meant as the latter, the "component".
But the introduction of the SDK has a whole page dedicated to Plugin Directory Structure. Here "plugin" is meant as the former, the "new functionality for Cinema 4D".

When I started developing ... "new functionality for Cinema 4D", a few years ago, it took me a while to understand that "plugin" was used with two meanings. At first I thought you could only write a "plugin" (new functionality) using one specific "plugin" (component) type.
It took me quite a while before understanding that you could have more than one "plugin" (components) into a single "plugin" (new functionality).

Just a few days ago, I needed to describe a problem, but it took me quite a while to figure out how to describe without confusing anyone, as I had this plugin, which consisted of plugins, which eventually resulted in missing plugins.

So far, I haven't yet made up my mind how I should further refer to "plugin" and "plugin" in order to distinguish them ...

Several years ago, when I started my first plugin, I didn't need to distinguish when referring to plugin in plural. Since I only had one plugin project, when I mentioned plugins, I meant multiple "plugins" (nodeplugin, commandplugin, ...) inside my plugin project.

Years went by, and now I do have quite a few plugin projects, each resulting in a cdl64, xdl64, dylib or xlib file. Still, each of these plugin projects consist of different "plugins".

Therefore, I was wondering what would be the appropriate term to use in order to distinguish between a plugin-file, something that the user refers to as "plugin", and the actual plugin, which represents a single entity, which represents a CommandData, NodeData, ToolData, DescriptionToolData, ...

I have created a custom GUI which I am using in the Attribute Manager.
No problems there.

I am registering the custom gadget using following piece of code:

Bool RegisterMyGadgetDataTypeGui()
{
	static BaseCustomGuiLib myMyGadgetGUIlib;

	ClearMem(&myMyGadgetGUIlib, sizeof(myMyGadgetGUIlib));
	FillBaseCustomGui(myMyGadgetGUIlib);

	// register the custom gadget as version 1.0.0.0 (= 1000)
	if (!InstallLibrary(MYGADGET_CUSTOMGUI_PLUGINID, &myMyGadgetGUIlib, 1000, sizeof(myMyGadgetGUIlib)))
		return false;

	if (!RegisterCustomGuiPlugin(GeLoadString(IDS_MYGADGETCUSTOMGUISTRING), 0, NewObjClear(MyGadgetCustomGUI)))
		return false;

	return true;
}

Now, I was wondering, since this is registered inside a plugin, what if I want to reuse this gadget in a different plugin project?
Do I simply copy over the source code for this gadget and perform the same registration call, using the same pluginID?
I understand that MyGadgetCustomGUI - which is derived from CustomGuiData - only needs to be registered once in a Cinema 4D session. But how to know if one or more plugins are installed which want to use the same custom GUI, and thus only one of these plugins should register the custom GUI?
Is there a manual, or detailed documentation available discussing this topic?

I did a search on "library" and all I could find was IsLibraryInstalled(Int32 id) , which makes me assume I should check in every plugin for the particular custom GUI library, and only install the library of not already installed. But then? Should I still perform the RegisterCustomGuiPlugin for this custom gadget, in every plugin?

Hello again,
I am having second thoughts, as I still would like to clean up the mistakes I made.
I want to filter out unneeded NodeData.
But how does the actual filtering work? What needs to be done?

Following is what I do for the needed NodeData:

1. In the main part of the plugin I register these NodeData plugins.
2. In the SceneHook::Init I allocate these NodeData and insert them in scenehooks' node branch.
3. For new NodeData that were introduced for new features, and are not yet available in older scene files, I allocate NodeData and insert them in the scenehooks' node branch during the SceneHook::Read.
4. In the SceneHook:Write I save all using following implementation

Bool MySceneHook::Write(GeListNode *node, HyperFile *hf)
{
	return mBranchHead->WriteObject(hf);
}

class MySceneHook : public SceneHookData
{
private:
	AutoAlloc<GeListHead> mBranchHead;

If I understand correctly, to filter out the unneeded NodeData I have to:

1. still register the NodeData plugin
2. skip allocating and inserting them during SceneHook::Init
3. skip allocating and inserting them during SceneHook::Read
4. ??? do what in SceneHook::Write ???

In theory, once all scene files have been updated (removed from unneeded NodeData), I then could also skip registering the needed NodeData plugins.

Main question thus remains, what to do in the SceneHook::Write ?

@s_bach
Order?
Ah, yeah! Sorry, I see why you assume I need a specific order from following sentence:
"as the obsolete NodeDatas need to be known in order to filter them out."
But what I meant to say was that I assume the obsolete NodeData need to be known, for them to be filtered out. Where "order" was not meant as meaning "a specific sequence".

So, I still need dummy plugins, and apparently it would also be better to have dummy NodeData to avoid issues?
I guess I better keep the original plugin and NodeData then. They're obsolete, so I could remove any processing implementation from their methods. But still leave them as is, instead of trying to replace them by dummy ones.

Thanks Sebastian,

I do register a SceneHook using a "level" value, which represents the version.
Each NodeData is created during SceneHook::Init and inserted into the scenehook's GeListHead

The SceneHook::Read performs a GeListHead::ReadObject and then checks the level value and there I create new NodeData introduced after that particular level value.

The SceneHook::Write does perform a GeListHead::WriteObject.

Should / Could I check for the particular level value and remove obsolete NodeData from the GeListHead before writing out?
Or do I need to filter out the obsolete NodeData during the Read?

Currently, the Init method does not create, nor insert the obsolete NodeData into the SceneHook's GeListHead (anymore). I suppose this needs to be reverted, as the obsolete NodeDatas need to be known in order to filter them out.
So, a convertor to read the old elements and removes them would be indeed what I am after.
How should I proceed?

I had noticed that the EVMSG_CHANGE was actually triggering the GetState of my CommandDatas, but I was wondering if a different approach was available.
Still, I am OK with the EventAdd() solution. Thanks.

I have this plugin where I have a SceneHook derived plugin, and several NodeData derived plugins. Over time I have created numerous scene files containing the registered NodeData-derived plugins. Having now realized some of these NodeData-derived plugins are obsolete, I thought of removing them from the project, and thus not registering them anymore. However, when I then open a saved scene file, it complains (obviously) about the missing plugins.

What options do I have to not register the obsolete plugins, but avoid the "missing plugin" warning?
Can I read the NodeData in the SceneHook somehow, and ignore it? Or do I still have to create a dummy NodeData derived plugin for the obsolete pluginIDs?

@m_magalhaes
Sorry, I didn't explain well enough.

I have a CommandData derived plugin with a GeDialog. The only gadget of the dialog is a GeUserArea.
In the userarea I draw items, which the user can "select" by simply left-mouse-clicking in the bounding box of the item.

Next I have several other CommandData derived plugins.
These are used to activate actions on the selected items.
What I try to perform is to enable/disable these "action" depending on the selected item in the userarea.

If I implement the SendParentMessage in the userarea (on successful item selection), it triggers the GeDialog::Command, which then triggers its parent with another SendParentMessage. But the parent of the GeDialog is its CommandData, while I need to trigger the "action" CommandDatas instead, in order to update their state.