Great, this is exactly what I needed. Thanks @ferdinand !

Hello @dunhou, ah that was the critical bit of information for me, that is you plugin at work there Well, as always without code it is hard to say what is going wrong there. the main code about this function is like : SetBit() doc.InsertMaterial() c4d.CallCommand(12252) # Render Materials doc.GetActiveMaterial() textag.SetMaterial() and some undo and call the Node Editor for certain renderer or rules for the function ... Out of this selection, I would put my money on CallCommand and undo handling. Setting bits and calling the mentioned methods are far less likely candidates. But that is pure guess work. actually, I checked the c4d.IsCommandChecked(id) The first thing I would do, is search for the command ID of the Material Manager (12159) in your code and add a print statement to each place where either this command ID is invoked with CallCommand or places where an ID determined at runtime is invoked (silly example : CallCommand(random.randint(1000, 1000000))) Then run your plugin again. When you see 12159 being printed when the undesired behaviour happens, you know it must be your plugin which misfiring. When not, it might be a bug in Cinama 4D or one of its APIs. Cheers, Ferdinand

Hi, Manuel. Thank you for description of both approaches, now I can compare them and choose the best. Regards, Sergey (Yesbird).

Hey @thomasb, no worries, don't be too concerned about it. And you should not be ashamed, that was certainly not what I wanted to convey. "Every person his or her book", the second so called law of library science, is something I truly believe in. Everyone has valid information needs and we are trying to help users on their individual journey. You should not feel discouraged, we are and were all once in your place. But at the same time, I sometimes have to regulate a bit forum conduct as we, the Maxon SDK group, and other users are human too. And people tend to get confused, when they are being hit with a stream-of-conscious like threads were a user comments diary-style-like on his or her development state. It is not that I would not understand people are doing that. When one is in that situation, one is overwhelmed by the possible routes one can take, the amount of information to traverse. And verbalizing that does indeed help. But for someone who tries to help you or for people who later search for similar information, this "stream-of-conscious/diary" is then an obstacle rather than a help. So, sometimes I try to regulate both interests a bit. But as I said, please do not feel discouraged. Cheers, Ferdinand

Thanks @m_adam I can confirm that the following does work with R20, R23 and 2023 Int32 MyDialog::Message(const BaseContainer& msg, BaseContainer& result) { BaseContainer keyChannels; if (GetInputState(BFM_INPUT_KEYBOARD, QCTRL, keyChannels)) { Bool ctrlModifier = (keyChannels.GetInt32(BFM_INPUT_QUALIFIER) & QCTRL) != 0;

@ferdinand Yes you are right, in relation to this the self.spline etc is unnecessary that could also be a normal local variable. Is correct. But basically if I load a profile spline in my init method, for example, I can already save it in such a variable. I need to be able to access it from anywhere in the class. But here it is totally superfluous....sorry

Thank you very much Maxime, both for the solution and the explanation. The code works perfectly. Also thanks for fixing this bug. Out of curiosity: Was this causing issues anywhere else? For completion sake: I do need to add a directChild->Free() after directChild->Remove(), correct? Still gonna mark this as answered as the core issue has been solved with flying colors. Thanks again!

hi, yes, KillDocument is not necessary in that case. Cheers, Manuel

Thank you.

@manuel Wow! Manuel thank you so much I'm new in code development so that's why its fo easy for me to have those kind of mistakes. Thank you so much for your support.

@m_adam Thanks. Works as expected!

Hi, there is this thread where Maxime is talking about drag and drop. If you have any question about it, please open a new thread. We like to keep question separated. Cheers, Manuel

hi, well you cannot inherit from the Hair Object as you could from a class. What you can do is to load the description of the hair object or include it in your description, create the hair object internally and link your description parameters to the internal hair object. Probably add your own parameter in your description. Than inside GVO you could generate the hair object with those parameter and return the result of it. While this seems to be possible, there are probably a lot of issue you are going to face, be ready ^^ Cheers, Manuel

@manuel Thank you very much!

Hello, @ferdinand Thanks, I will take it into account. All the best, ... YB

Creating an instance for each subdialog solved the issue thank you so much.

@m_adam Thanks for you reply , and there is nothing worry about the time, you are much busier than me I already try the defaultX and nothing changed, the dialog is always bigger than I set , it seems the dialog is considering teh hiden element size or something , the code is bit long for the forum ( maybe we should add a folding option to the code block in the forum ), and I sent an copy to ferdinand , and newest version has nothing changed for the UI part, Is that convenient for you to get a copy from ferdinand or post your email I can send you emails to, Cheers~

hi, well, if it works. Cheers, Manuel

Hi @ferdinand , I get it ! Thanks again to your reply!

Hello @herrmay, Yes, it can be a bit cumbersome to write a whole abstraction layer, but most of the time it is avoidable to do that in the first place. In your case it should be pretty simple. Iterate over all layers you want to save to disk. Get the MAXON_CREATOR_ID UUID of each layer and its data container. Write the UUID and the data container to disk using JSON or HyperFile, I would recommend the latter as it will be less work. You only must convert the UUID bytes to a string, put the string into the file, then the data container and you are done. If you want to, you could also store all layer data in one file per document, or just have one giant file for all documents. Later load these hyper file fragments back and do what you want with the data. When you need the original node, traverse the layers in the active document for a node with the stored UUID. You could also make things fancier and search in all open documents or even store the document path in your serialized data and load that document. Saving things in the document container is a possibility too, you should make sure though to use a plugin ID for that. Cheers, Ferdinand