Problem Adding description parameter by clicking button and access this
-
@manuel
sorry manuel for another question depending this and probably annoying you.
so I want to go the save way:
so in my quicktabradio for the basement type , the user can choose between 3 different types.
At the moment the base will cloned and inserted in the virtual document under a null....I can change this so that this is not happening in the GVO method.
But I need to catch the message for the parameter change in the Quicktabradio for the basetypeI tried:
if type == c4d.MSG_DESCRIPTION_POSTSETPARAMETER: # for key in data: # print("key:", key) # print("val:", data[key]) if data['descid'][0] == c4d.PY_BASE_TYPE: print("yes")
nothing happens
when I catch a button I catch id with:
if type == c4d.MSG_DESCRIPTION_COMMAND: if data['id'][0].id == c4d.PY_ADD_LEVEL: print("Something")
this works.
so I printed out the dict and get the key "descid" but this doesn't work, how can I catch this Quicktabradio change in my description in the message method?Best Regards
-
So I do not really know how to catch this Quicktabradio switch correctly. At the moment I have this in my level object Message() method:
I tried to catch the parameter "PY_LEVEL_TYPE" of the Level-Plugin and I also tried to catch the MainThread. I don´t know if this is correctdef Message(self, node, type, data): parent = node.GetUp() if type == c4d.MSG_DESCRIPTION_POSTSETPARAMETER: if data["descid"][0].id == c4d.PY_LEVEL_TYPE: if c4d.threading.GeIsMainThread(): if parent != None: c4d.CallButton(parent, c4d.PY_REFRESH)
it works but prints out some errors in the console:
AttributeError:'function' object has no attribute 'im_func'
I just want, when I switch the Quicktabradio, that the citybuilding-plugins "Refresh" Button is called or to send a Message to the CityBuildings plugin and catch this message and then do something.
Best Regards
-
Hi,
We like to have different thread for different question even if it is related to the same project. I forked that thread. The question regarding the license will be discussed on this thread
@thomasb said in Problem Adding description parameter by clicking button and access this:
it works, I'd just forgotten to return True in my Message method of the Level-Object
It is sometimes a bit hard to follow people's project specially when we are bending a bit the rules. I am glad it is working.
Cheers,
Manuel -
@Manuel said in Problem Adding description parameter by clicking button and access this:
Hi,
...........The parameters values are stored (most of the time) in the BaseContainer so be careful, you need to "clean" the BaseContainer each time you delete a level, otherwise it will reload the previous values.
.............
Cheers,
ManuelSorry Manuel ,
it took a while to work out a few things, so now I am ready for your answer.
So here is an example plugin, I made it to create description elements by clicking a button. So this example is better for the answer you hopefully can give me.
I keeped track of the ID`s as you recommended in an array.
So when the user clicks the button Add Measurement a new ID will be created in the array. And accordingly to that, a Group with this ID will be created in the description and a Baselink, a real and a Delete Button will be added to the group. Just for example.
I have also overwritten Read(), Write() and Copy() methods.And when the user clicks "Delete", the ID will be deleted from the array and so the group and it's parameters dissapear.
So when the user clicks again "Add Measurement" then it searches the array and the next smallest ID that is not in the array is used again. To save some ID`s . God saves the ID's
But since this ID already was in the description. It is not empty as you can hardly see in the small video example.You told me something about cleaning the BaseContainer?
-
Hey @ThomasB,
I would not reuse the identifiers of previously removed parameters (when avoidable) as this does violate the Cinema 4D design pattern that parameter identifiers express a purpose. I.e., a parameter Foo with the ID
1000
should not be relabeled as the parameter Bar (with also the ID1000
) . Which is effectively what you are doing here.As you have discovered yourself, you will then run into value history problems. Other things that can cause problems are undo states that are inexplicable for the user and the preset system.
C4DAtom
parameter identifiers below the value1,000
are reserved for Cinema 4D. Plugin identifiers start at the value1,000,000
, we should not go above this value because there could be other plugins which write data under such plugin ID into the data container of our node. Static parameter identifiers for a plugin, i.e., what you define in a header file, usually do not exceed the value20,000
. Which means that we have980,000
identifier slots left. There is no need for any house keeping with our identifiers, even when we reserve them in blocks.A good pattern to setup header files for dynamic descriptions is this:
// Header for Oexample object hook description. #ifndef _OEXAMPLE_H__ #define _OEXAMPLE_H__ enum { // The identifiers for static parameters. ID_GRP_EXAMPLE_MAIN = 1000, ID_VAL_EXAMPLE_MAIN_DIAMETER, // ... ID_GRP_EXAMPLE_OPTIONS = 2000, ID_VAL_EXAMPLE_OPTIONS_BLAH, // This just a normal enum, we can define here whatever we want, including values that are not // referenced in the res or str files. // These values express the range in which dynamic IDs can be found, i.e., the lowest ID can // be 10,000 and the highest 20,000. Your plugin has still to conform to that, but it is a good // idea to express such information in the header file of the resource. ID_EXAMPLE_DYNAMIC_IDS_START = 10000, ID_EXAMPLE_DYNAMIC_IDS_END = 20000, // The stride with which "logical parameter blocks" are placed. By just reading the header file // we now know that there are 10,000 dynamic IDs going from 10,000 to 20,000, placed with a stride // of 100, resulting in up to 100 dynamic parameter groups. When this is not enough, you can easily // also set #ID_EXAMPLE_DYNAMIC_IDS_END to 200,000 to have 1000 item groups. Or also make your // stride smaller. A value of 100 is probably a bit wasteful for a use case of only a handful of // parameters. ID_EXAMPLE_DYNAMIC_IDS_STRIDE = 100 } #endif // _OEXAMPLE_H__
You should also remember to initialize your dynamically added parameters. Which you do not do at the moment in
GetDDescription
. Doing this will get rid of the problem of 'lingering' values with your current design, but the other problems would remain.Cheers,
Ferdinand -
@ferdinand said in Problem Adding description parameter by clicking button and access this:
Plugin identifiers start at the value 1,000,000,
you probably meant end or?
ok this was my first idea, but my ids starting from 10000
Manuel just said above that you have to empty the BaseContainer, so thought not a bad idea at allcan you still tell me how to empty the container?
if not also ok
I mean I certainly need that in other situations too.The user deletes the ID, all parameters in the group must be reset.
Have a nice day.
-
Hi @ThomasB,
you probably meant end or?
No, I meant start. The upper limit of plugin IDs, i.e., "end", is simply
+2147483648
, the maximum value a signed 32 bit integer can take. The largest plugin ID assigned at the time of writing is1061082
:Internally, there are exceptions and Cinema 4D ships with some plugins with an ID below
1,000,000
but we can ignore them. The reason why we must respect plugin IDs is that they can also be used as a globally unique address for data containers. I.e., someone could registerID_MY_DATA: int = 1061083
to write his or her data into the data container of a node implemented by you. The plugin ID is then meant to ensure that your plugin does not accidently overwrite that data. From which follows that parameter identifiers should not exceed the value999,999
.can you still tell me how to empty the container?
You are not really meant to delete a value of a node, you are only meant to modify the data model, i.e., add, remove, or modify parameters. You can call BaseContainer.RemoveData on the data container of a node to remove an entry. But that is not really deleting the value (history).
As stated before, setting a default value once a "new" parameter has been created will fix your problem, even with your current design. No need for deletion. I am not quite sure why Manuel did recommend this pattern, only he can explain that.
Cheers,
Ferdinand -
Ah plugin ID. Sorry, I thought you meant the IDs for the description parameters. Yes, PluginID. Yes, I didn't take that into account when writing the example code
Ok, yes, that would be the best solution to add new unused ids for dynamic ids. I will definitely do that.
But if the user would press a dynamically created reset button, could I use BaseContainer.FlushAll() to only reset the values in that ID group?
Or do I have to use the SetParameter() Method for all parameters.So if the user has made some settings that don't quite fit and he wants to reset all dynamic parameters in the dynamic group... So they have to be set to the default value.
Best Regards
Thomas -
@ThomasB said in Problem Adding description parameter by clicking button and access this:
You told me something about cleaning the BaseContainer?
2023-05-11 01-11-45.mp4hi, that is exactly why i was talking about cleaning the BaseContainer, or to initialise correctly the values. It is even worse if you mix datatype.
I was thinking of the morph tag and the way he does add or remove morph target using the same IDs.
And of course, removing data that you are not using anymore is a good idea.
Cheers,
Manuel -
@Manuel
and how do I initialise the parameter if the user presses for instance reset.
With Atom.SetParameter(), right? -
You can use SetParameter or change the value directly in the BaseContainer. Using SetParameter is a better option if you want to move the data anywhere else outside the BaseContainer. If you do so, you will have to override the NodeData.SetDParameter function to handle your data properly. (note the difference, there is a D in that function name)
Calling SetParameter will work on both cases, storing your data in a BaseContainer or in your own way.
It is always a clever idea to initialise your data.I would rather clean the BaseContainer when you press the "delete" button. That will avoid having a BaseContainer getting bigger and bigger, especially if you copy paste your generator from document to document.
Cheers,
Manuel -
This post is deleted! -
This post is deleted! -
@ferdinand
I hope it's ok to delete old posts to which I found the answer myself.So after I have removed now the Data from the Container.
I also keeped track of the already used ID´s in a member variable, to follow your intructions related the Cinema 4D Design pattern.But is it now also necessary to overwright Read, Write and CopyTo Methods
Or is this negligible, when loading the scene again.-
For Instance 10000 and 10100 will be created,
-
then 10200 will be created and deleted.
-
An new ID will be created again and gets the ID 10300. (10200 already was used)
-
Then this 10300 will be deleted again.
-
The document will be saved.
-
After loading the document and creating a new ID , next ID will get 10200.
Does this matter. Or is this also important to keep track of the already used ID´s when loading a new doc, or copying the node instance.
Or does it not matter in this case.Initializing Dynamic parameters:
I still do not now how to Initialize a dynamically created parameter.
I used the DESC_DEFAULT but this seems not to be the right thing.
I look into the plugin example in the sdk for dynamically created parameters.
But this is not really clear for me where he initializes the ID's. He just appends them to a member variable.I thought this maybe also works with BaseContainter.SetFloat(c4d.DESC_DEFAULT, 50.0) but yes, puff cake
-
-
Hello @ThomasB,
first of all, when you store your data in the data container of the node, you do not have to overwrite
NodeData.Read
,.Write
, and.CopyTo
as the data container is automatically serialized and deserialized. These methods are only necessary when you want to serialize things which technically cannot, perform badly, or are otherwise undesirable to be expressed in aBaseContainer
format.The automatic serialization of things in the data container of a node applies to all data, i.e., including your dynamic parameters. This is also why I mentioned the rule that your parameter IDs should not exceed
999,999
because other plugins sometimes store data under their plugin ID in your node.Regarding the ID order. When a new document has been loaded, all the value history data is newly initialized and reusing IDs would therefore not have the same effect anymore. So, things should not be that bad anymore. In the end, there is no absolute right or wrong here, and it depends and what you do. You could also just add a parameter (without an UI, i.e., just an enum value in the header file) to your node which always holds the last used ID slot.
When you play this game long enough, you will of course run at some point out of IDs. But for a stride of
100
and a possible dynamic ID range of[10,000:999,999]
you have9.899
bins, so users would REALLY have to work for reaching that limit.I personally would for sure build a fail-safe into my plugin that prevents it from going over the ID-limit. I personally would also ensure that parameters that are visually consecutive in the GUI are also consecutive in the data container, i.e., not reuse IDs. If you wanted to, you could also implement a parameter compacting routine which upon a node being allocated, i.e., when there is no value history, compacts parameters from somthing like
[10001, 10004, 10006]
to[10001, 10002, 10003]
so that you can never run out of IDs. I personally would probably not do that given how unlikely such overflow is, I would simply live with the fact that the plugin would stop the user from adding new parameter groups after 10,000 items.But you can also just reuse IDs, it all depends on how you implement things.
Cheers,
Ferdinand -
Hello @ThomasB ,
without further questions or postings, we will consider this topic as solved by Friday 02/06/2023 and flag it accordingly.
Thank you for your understanding,
Maxime.