hi, without further feedback i'll set this thread as solved tomorrow. Cheer, Manuel

@PluginStudent You mentioning the BITMAPBUTTON and with the help of ExampleSculptGrabBrush::GetDDescription from the cinemasdk I was able to make it work. Thanks.

Hi, without further feedback, we will consider this thread as solved by tomorrow and flag it accordingly. Cheers, Ferdinand

Yes, I use the auto way. I thought that using ScrollArea() it would only display that part (no need to draw the other parts). So, fill the virtual UA once and then display parts of it using ScrollArea(). But if "you still need to draw completely the GeUserArea with all the DrawBitmap", there will be no speed benefit. I will try it under R21 and will read "Profiling Python Plugins". Thank you, Pim [image: 1586507628642-24fbc034-a80c-42f0-acb3-77deffeadaec-image.png]

@m_adam @zipit @PluginStudent OK, thank you guys!

It's actually due to a lower number of bits used to store the floating value.

Thanks! seems to work well! the problem is that apparently it only runs on the tag, if I set the option as a UserData of my object, it doesn't work

hi, that really depends on what you are doing. There's different type of lock for different cases and scenario. That also depends on what you care first, speed or memory. but the manual is pretty easy to understand, just pass the lock as a reference to your lambda function and you should be good to go. Cheers, Manuel

Thanks for the drag'n'drop tip Maxime, that feature is extremely useful!

Hi, yeah like that. __name__ is just another module bound constant attribute. It is a dunder attribute, signaling a special importance, indicated by its double underscores, but that is only a convention and not a functionality. You can set __name__ to anything you like, just like you could set __author__ to your favourite ice cream brand. The convention dictates that __name__ tells the script in which context is being executed, where __main__ should signal that the module is executed directly. You could set it to my_cpp for example, so that your scripts could react differently to being executed from your C++ code. Cheers, zipit

Thank you!

Ok, thank you. I should have spotted that myself. -Pim

To summarise, there are 2 projectdefinition.txt files. on main / sdk level, Define which project (plugins, etc.) Example: Platform=Win64;OSX Type=Solution // defines the level of rigour of the source processor's style check stylecheck.level=0 Solution=\ plugins/cinema4dsdk;\ plugins/maxonsdk.module;\ plugins/commandline;\ plugins/CommandLineRendering on plugin level, // Configuration of a custom solution in the projectdefinition.txt file Example: // Supported platforms Platform=Win64;OSX // Type of project Type=DLL // this plugin depends on these frameworks: APIS=\ cinema.framework; \ misc.framework; \ image.framework; \ core.framework; \ python.framework // Enable some advanced classic API support; not needed for hybrid plugins C4D=true // Plug-in code-style check level stylecheck.level=0 // Custom ID ModuleId=net.maxonexample.commandlinerender

@r_gigante said in attribute 'nodiscard' requires compiler flag '/std:c++17': Well @pim , that's indeed the issue. Sticking to the recommended IDE is always recommended. Indeed going back to VC++2015 solved the issues. But now I have problems with the python.framework. See https://developers.maxon.net/forum/topic/12439/reading-script-file-into-memory/8

Thank you Manuel !! this is exactly what I was looking for

@r_gigante Well ... this is embarrassing. I came up with the R21 code using notes I had collected over the years, and was rather confused seeing this didn't port over to R20. Actually the correct code should look like following: Bool MyUserArea::InputEvent(const BaseContainer& msg) { const Int32 dev = msg.GetInt32(BFM_INPUT_DEVICE); const Int32 chn = msg.GetInt32(BFM_INPUT_CHANNEL); if (dev == BFM_INPUT_MOUSE) { if (chn == BFM_INPUT_MOUSEWHEEL) { const Float wheel = msg.GetFloat(BFM_INPUT_VSCROLL) / 120.0; Int32 mx = msg.GetInt32(BFM_INPUT_X); Int32 my = msg.GetInt32(BFM_INPUT_Y); Global2Local(&mx, &my); ApplicationOutput("Mousewheel value @ at x=@, y=@", wheel, mx, my); return true; } } return false; } No need at all to perform a GetInputState to obtain the the x and y coordinates from, as the BaseContainer to get it from is already provided as "msg". And this works both for R21 and R20. Man ... sometimes you think you know what you're doing, and then it seems you just know squad. Embarrassing! Riccardo, terribly sorry for wasting your time!

Thanks for the response, that's exactly what I needed. John Thomas

Hello and welcome to the forum, For your next threads, please help us keeping things organised and clean. I know it's not your priority but it really simplify our work here. Q&A New Functionality. How to Post Questions especially the tagging part. I've added marked this thread as a question so when you considered it as solved, please change the state In your code you Resize the object after initialized for the modeling command. That's why. but probably a simpler way to achieve what you want is to access the polygon's data. The PolygonObject is inherit from PointObject where you can retrieve the pointer of the points' vectors with GetPointW sometthing like so will work Vector* padr{ pol->GetPointW() }; if (padr == nullptr) return maxon::NullptrError(MAXON_SOURCE_LOCATION); padr[3] = Vector(-2, 0, 0); You can have a look at our "roundtube" example in the sdk.zip file that ship with every Cinema 4D version. This example will show you how to create a primitive from scratch. Cheers, Manuel.

thank you so much!!

I need to spend some further consideration since it looks like I was unprecise. When the BaseArray::Append() and the capacity of a BaseArray is reached - BaseArray default size is 16 elements - the internal BaseArray::IncreaseCapacity()is called and it sequentially allocates a new memory block, copies the values of the previous block to the new one, and then the old one is released. Being the values passed to the BaseArray::Append() a reference to myArray[0], it references the first element of the old block and because the code in Append() accesses the reference after the old block has been released, that access is illegal. @r_gigante said in Fun with maxon::BaseArray: To temporarily mitigate it you have to cast the value returned from the [] operator before appending it to the proper type. Actually by writing Int32(myArray[0]) - and here I was indeed unprecise because it is NOT casting but temporary local creating of a copy - a local Int32 copy of myArray[0] is made on the stack at first by the compiler (before calling Append) and then Append(Int32(myArray[0])) references that local copy which is legal. This behavior is NOT a bug - another initial overlook of mine - but rather a behavior by design which for example is also part of std::vector::push_back(). So, as a rule of thumb, cases where references to array elements are used while the array gets resized must be avoided. This note will be added to the BaseArray Manual in our documentation. Sorry for the confusion I initially generated and, if further clarification are needed, feel free to come back. R.