Confusing ToolData content
-
I am playing with the Attribute Manager, and tried reading out the ToolData of some selection tools using following script:
# Read out the BaseContainer from ToolData import c4d def main(): print " --- read ToolData BaseContainer ---" toolID = doc.GetAction() tool = c4d.plugins.FindPlugin(toolID, c4d.PLUGINTYPE_TOOL) print "Active tool = %s (%i)" % (tool.GetName(), toolID) # parse the tooldata toolbc = c4d.plugins.GetToolData(doc, toolID) i=0 for elementID, value in toolbc: elementType = toolbc.GetType(elementID) print "%i ID: %i, Type: %i, Value: " % (i, elementID, elementType), value i+=1 if __name__=='__main__': main()
The output for the Live Selection tool was as expected. All attributes of the tool being visualized in the Attribute Manager can be found back in the printed output.
But then I selected the Rectangle Selection and executed the script once more. To my surprise very few attributes were printed out. Same for the Lasso Selection and Polygon Selection.--- read ToolData BaseContainer --- Active tool = Live Selection (200000083) 0 ID: 2108, Type: 15, Value: 1 1 ID: 2109, Type: 15, Value: 10 2 ID: 2200, Type: 15, Value: 0 3 ID: 2124, Type: 15, Value: 0 4 ID: 2125, Type: 19, Value: 1.0 5 ID: 2169, Type: 15, Value: 1 6 ID: 2163, Type: 15, Value: 0 7 ID: 2164, Type: 15, Value: 0 8 ID: 2201, Type: 15, Value: 0 9 ID: 2202, Type: 19, Value: 100.0 10 ID: 2203, Type: 19, Value: 1.0 11 ID: 2204, Type: 15, Value: 0 12 ID: 2205, Type: 15, Value: 0 13 ID: 2206, Type: 15, Value: 0 14 ID: 2207, Type: 19, Value: 0.5 15 ID: 2209, Type: 15, Value: 1 16 ID: 2208, Type: 1009060, Value: <c4d.SplineData object at 0x000000B81496D250> 17 ID: 2129, Type: 15, Value: 0 18 ID: 2130, Type: 19, Value: 1.0 19 ID: 2131, Type: 19, Value: 0.0 20 ID: 2132, Type: 19, Value: 1.0 21 ID: 20000, Type: 15, Value: 2 22 ID: 20001, Type: 15, Value: 0 23 ID: 20003, Type: 19, Value: 0.0 24 ID: 20004, Type: 19, Value: 0.0 25 ID: 20005, Type: 19, Value: 0.0 26 ID: 20006, Type: 15, Value: 0 27 ID: 705, Type: 15, Value: 1 28 ID: 20002, Type: 15, Value: 0 --- read ToolData BaseContainer --- Active tool = Rectangle Selection (200000084) 0 ID: 2107, Type: 15, Value: 1 1 ID: 2106, Type: 15, Value: 0 2 ID: 705, Type: 15, Value: 1 --- read ToolData BaseContainer --- Active tool = Lasso Selection (200000085) 0 ID: 705, Type: 15, Value: 1 --- read ToolData BaseContainer --- Active tool = Polygon Selection (200000086) 0 ID: 705, Type: 15, Value: 1
So, I am rather confused about the content of the ToolData for the last 3 selection tools.
These printed output don't reflect the tool's attributes seen in the Attribute Manager. Are these attributes stored somewhere else perhaps?
Or is my script wrong in some way? -
Hi,
no your script is not wrong. There's just a bit more to it.
- To state the obvious, there's no reason, why different tools should have the same ID for a parameter's data, even if these parameters are called identically in the user interface.
- Just like every other
NodeData
derived entity, a tool does not necessarily store it's parameters in theBaseContainer
. Or it may store values in the BaseContainer, only, if it's different from default. Either way, you have no guarantee to find all parameters in the BaseContainer. Rather useGetParameter()
(so in your case for exampletool.GetParameter(2108, c4d.DESCFLAGS_GET_0)
)
Cheers,
Andreas -
Thanks Andreas,
I get your first point, and wasn't actually expecting same IDs. But in case of Lasso tool I didn't expect to only get a single attribute.
However, for your second point. I can relate not all attributes to be available in theBaseContainer
... if that is how it was designed.
And I am fine with usingGetParameter
if that gets the job done. But how am I supposed to know to get parameter with ID 2108 in your example?
I mean, if I cannot browse through aBaseContainer
in order to find out which attribute IDs are available, how could I then perform aGetParameter
? How do I know which attributes are available to a tool?So, I guess the
Live Selection
was just a lucky shot, where everything was available in the BaseContainer obtained viaGetToolData
? -
You could for example check the resource files for available parameters.
Or you could call GetParameter() for a certain ID range, it will return None, the parameter doesn't exist. -
Sorry, both are not an option in this case.
The purpose is to automatically read out settings of a tool (plugin in general), store it, perform changes, use the tool, and reapply the original settings. -
Hi,
you can also use the
Description
.With a small loop, you can get information about a tool's parameters and their type:
toolID = doc.GetAction() tool = c4d.plugins.FindPlugin(toolID, c4d.PLUGINTYPE_TOOL) desc = tool.GetDescription(c4d.DESCFLAGS_DESC_0) for bc, paramid, groupid in desc: # Iterate over the parameters of the description print bc[c4d.DESC_NAME], paramid[0].dtype # Print the current parameter name and type
It sounds a bit, as if you try to create some kind of undo system for tools. Something Cinema 4D does not have currently. The standard undo system for example works by cloning instances, something that is not possible with tools. But of course the cloning automatically takes care of the entire instance's state, regardless, if parameters are stored in the
BaseContainer
or if the complete state is really defined by parameters.
So, just be aware, even with the above approach, there might still be information stored inside of a tool, which may not be reflected by theDescription
, either. I have no examples for this, it is more a word of a warning, something like this might come up.Cheers,
Andreas -
I am looking into the
GetDescription
solution you discussed. It takes a little more to translate from Python to C++, but I see the possibilities. Although this introduces more clutter to sift through.
I guess I was spoiled with the result I got from just testing out the Live Selection and Extrude tools, in order to see how to design the whole framework behind.
Didn't think other (native) tools would be so problematic.I am not working on some kind of undo system, more a workflow enhancement.
My Dials plugin allows to quickly set up a set of most used tools. People refer to it as a radial menu, but it definitely is not.
One of its feature was the ability to provide for a set of "favorites" where most used settings for tool could easily be "cached" and quickly retrieved.
From my modeling times (before I started spending most of my time on plugin development) I remember having constantly the need to have 2 or 3 bevel settings at hand. As such I needed to modify the values constantly. With the introduction of Dials and its favorites, I now would simply store a few settings and retrieve them on the fly.A quick work-in-progress demonstration (of the favorites idea) if I may ...
Hope this helps put the "get basecontainer" idea into context.
-
Hi,
thanks for the insight. Sounds nice!
I wasn't aware you were looking for a C++ solution, as the initial post contained Python code and als the thread's tag said Python... well, now you'll port it yourself.If I may suggest something, after looking at the video. Why not simply show the description of the tool in your dialog (like the Active Object Manager example does)? Then the user could set all parameters in one step and save them to a preset with a click.
Cheers,
Andreas -
Strange the thread has only a Python tag. I was almost sure to have only enabled R19, R20 and C++ tags.
Maybe I was not fully awake when I created the thread ... or to focused on copying the C++ code into a Python script to demonstrate the purpose. (Updated the tags)Anyway. Converted your GetDescription example to C++ (or at least to the best of my knowledge).
Your suggestion to show the description of the tool in a dialog is what I was trying to avoid.
I would like to keep the dialog small, and want to avoid duplicating the Attribute Manager. So, the drag and drop is the better solution (in my opinion).
Besides, if I would want to display the description, I would still need to parse it.Currently I store the basecontainer obtained from
BasePlugin* const plug = static_cast<BasePlugin*>(draggedAtom); const Int32 id = plug->GetID(); BaseContainer* tooldata = GetToolData(GetActiveDocument(), id); mDialWidget->StoreFavorite(tooldata);
Guess I 'll need to do something similar, but with the obtained description.
... Will keep you posted.
Thanks for thinking along. -
Had a closer look at
Description
and while it was easy enough to work withBaseContainer
(obtained fromGetToolData
), I see some troubles with the former.
First, no default constructor is publicly available. This means I'll need to work with pointers (AutoAlloc
). Not a big issue.
But I also don't see anyCopyTo
norCopyFrom
available. Nor cloning.
Furthermore, when I want to store the retrieved description from a tool, I would do so into a plugin container (GetWorldPluginData
).Couldn't find anything related to a Description Manual, so I am not really visualizing what a Description actually is, besides a list of descriptions.
I will need to investigate some more, and figure out how to actually "process" the obtained description in order to store and retrieve all of its data, and apply it back to a tool.
Easy peasy with a basecontainer, not so with a description ...Still don't get the point why most tools have all stored into a single basecontainer, while lasso, rectangle and polygon selection tools deviate from this. There might be some others tools which deviate as well, but haven't encountered them yet.
So, what's the point of having aGetToolData
when it doesn't actually returns the tool data ??? -
@c4ds said in Confusing ToolData content:
Couldn't find anything related to a Description Manual
Hello,
there is a Description Manual.
best wishes,
Sebastian -
Regarding the embedded description GUI, I was just thinking loudly. I understand your design decision completely.
And actually I didn't want to imply, you should store the Descriptions (after all these contain no values). I thought more of a combination of the GetParameter() approach (where you were lacking the information, which parameters exist) and the description code I suggested. So you could during your initialization (in your case probably, when the user drags a new tool onto the wheel) find out about all available parameters and with this prepare a BaseContainer to store whatever you need later on.Cheers,
Andreas -
In the meantime I am able to parse the Descriptions and iterate over the available entries and perform a GetParameter.
ANodeData
derived object can implementGetDEnabling
to indicate if an element is to be set enabled or disabled. How would one go about retrieving this state from the Description elements?
And what about theDESC_HIDE
flag, is that accessible as well somewhere?I understand the Description Manual is meant for the regular way of using the descriptions (in a NodeData derived plugin), so obviously I will not find answers there related to my extreme use-case.
-
Hello,
The information if a parameter is enabled is not stored in the Description object. You can use
C4DAtom::GetEnabling()
to check if the parameter is enabled (see C4DAtom Manual).DESC_HIDE
is stored in the Description object as usual. See Description Settings Manual.Best wishes,
Sebastian -
Thanks for the links Sebastian.
Had read these before, but still cannot figure out how to process the DESC_HIDE. I simply don't get it.I am trying with a Python script, as this is faster to prototype.
import c4d def main(): toolID = 431000015 # Bevel (id obtained from script log) tool = c4d.plugins.FindPlugin(toolID, c4d.PLUGINTYPE_TOOL) print "Tool = %s (%i)" % (tool.GetName(), toolID) # parse the description desc = tool.GetDescription(c4d.DESCFLAGS_DESC_0) for bc, paramid, groupid in desc: elementID = paramid[0].id # for testing purposes we are only interested in the "Apply" button if elementID != c4d.MDATA_APPLY: continue print bc[c4d.DESC_NAME], paramid, groupid print "Hidden = ", bc[c4d.DESC_HIDE] if __name__=='__main__': main()
With the above I do get
None
as result for theDESC_HIDE
.
It might be explained in the manuals, I just don't get it. Sorry! -
Hello,
not every parameter description stores a value for
DESC_HIDE
. Typically a component only sets the value if it wants to hide a specific parameter.So depending on how to access the value, the access might fail. E.g.
GeData data = bc->GetData(DESC_HIDE); if (data.GetType() == DA_LONG) { const Bool hide = data.GetBool(); ApplicationOutput("DESC_HIDE: @", hide); } else { ApplicationOutput("DESC_HIDE not set"_s); }
cannot read
DESC_HIDE
if the value is not stored in theBaseContainer
.You can access
BaseContainer
values using functions like GetBool(). Such a function allows you to define a default value that is returned if no value is stored in theBaseContainer
:const Bool hideStatus = bc->GetBool(DESC_HIDE, false); ApplicationOutput("DESC_HIDE status: @", hideStatus);
See BaseContainer Manual and GeData Manual.
Best wishes,
Sebastian -
I do get all you are trying to explain. It all makes sense ... it does.
Still, I am unable to read out the attribute information I am looking for.import c4d def main(): # get the current active tool toolID = doc.GetAction() tool = c4d.plugins.FindPlugin(toolID, c4d.PLUGINTYPE_TOOL) print "Tool = %s (%i)" % (tool.GetName(), toolID) # parse the description desc = tool.GetDescription(c4d.DESCFLAGS_DESC_0) for bc, paramid, groupid in desc: elementID = paramid[0].id # for testing purposes we are only interested in the "Apply" button if elementID != c4d.MDATA_APPLY: continue # the Bevel tool has the "Apply" button visible (sometimes disabled, but visible) # the Live Selection tool has the "Apply" button part of its description, # but this button is not visible, it should thus have its DESC_HIDE set to true ??? # Select the bevel tool and execute this script => "No DESC_HIDE" # Select the live selection tool and execute this script => "No DESC_HIDE" !!! # >>> How to get the Live Selection's hidden state of MDATA_APPLY ??? gd = bc.GetData(c4d.DESC_HIDE) if gd == None: print "No DESC_HIDE" elif bc.GetType(c4d.DESC_HIDE) == c4d.D_LONG: print "DESC_HIDE = ", bc.GetBool(c4d.DESC_HIDE, False) else: print "DESC_HIDE not LONG" if __name__=='__main__': main()
-
Hello,
the descriptions are based on description resource files (see Parameter Description Resources). In
toolbase.res
you see thatMDATA_APPLY
is part of the groupMDATA_COMMANDGROUP
:GROUP MDATA_COMMANDGROUP { DEFAULT 1; GROUP { BOOL MDATA_INTERACTIVE { } GROUP { COLUMNS 3; DEFAULT 1; BUTTON MDATA_APPLY { FIT_H; } BUTTON MDATA_NEWTRANSFORM { FIT_H; } BUTTON MDATA_DEFAULTVALUES { FIT_H; } } } }
In the live selection's resource file
toolliveselection.res
you see that the base is included but theMDATA_COMMANDGROUP
group is hidden:INCLUDE ToolBase; ... HIDE MDATA_COMMANDGROUP;
Therefore,
MDATA_APPLY
has noDESC_HIDE
setting. The whole group is hidden usingDESC_HIDE
.Inside Cinema this is checked like this:
BaseContainer *groupData = desc->GetParameterI(MDATA_COMMANDGROUP, nullptr); if (groupData != nullptr && groupData->GetBool(DESC_HIDE)) return true; BaseContainer *applyData = desc->GetParameterI(MDATA_APPLY, nullptr); if (applyData != nullptr && applyData->GetBool(DESC_HIDE)) return true;
best wishes,
Sebastian -
@s_bach said in Confusing ToolData content:
The whole group is hidden using DESC_HIDE.
Ah ... didn't even consider that one.
This makes perfect sense.Thanks for going through all the trouble of explaining.
-
Congrats on the new forum! it is very informative
About time