@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 @m_adam, for now I've added a workaround for older versions so it's not possible to drag the buttons to the layout. Works for me, but would be nice to know anyway. Thanks, Lasse

Thank you Manuel! :) I appreciate it! Andre

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.

hello, I will consider this thread as solved without new information from you :) Cheers, Manuel

You're welcome, Manuel. Actually, I usually prepare all the textures and mapping to be in UVW mapping, when texturing is required. But, mainly, what I need is exporting geometry that is animated.

My apologies: I didn't understand how BaseLink worked and this clarified things. Thank you!

@lasselauch said in SetData() with FindCustomGui / CUSTOMGUI_BITMAPBUTTON: there's no way to flush a single Element and insert at that position, right? It has to be a group For what I know, correct. Cheers, Manuel

Hi Daniel, the reason why it worked "as expected" on older revision was by pure chance - as much as it was for the Redraw thread. Cheers,

@s_bach said in Plugin not found after switching layout: The ID used with GeDialog::Open() andRestoreLayout() is typically the plugin ID of the CommandData plugin. See e.g. activeobject.cpp Thanks. It had to be something so simple I kept missing when reviewing the code.

@m_adam Thanks, Maxime, for the temporary workaround and for bumping it to the development team. I hope this is fixed soon!

Hi @wuzelwazel, thanks a lot for sharing your progresses on the Ptex Shader and for sharing your code. I've moved the thread to the more appropriate "General Programming & Plugin Discussions" hoping other developers could contribute to the discussion. Cheers, Riccardo

Hi, This is solved in the last documentation update, see BaseBitmap.ScaleIt. Cheers, Maxime.

Hello, thanks for sharing this with the everybody. COLOR_TIMELINE is now EX_COLOR_TIMELINE the documentation will be updated to reflect that change. Cheers, Manuel

https://plugincafe.maxon.net/topic/11570/plugin-affecting-c4d-modules-startup/9

Hello, as Riccardo has pointed out, AdditionalIncludeDirectories has nothing to do with DLLs. It is used to define search paths for header files. See Additional include directories. It was never valid. Also, looking at the error, the plugin was installed into the C:/Program Files folder. In R21, there is no reason to install plugins there; one can install plugins at any location and just tell Cinema 4D the plugin path. best wishes, Sebastian

Hi Maxime, thanks a lot! Both are valid solutions for me. Very helpful. Cheers

@m_adam You are a legend! I've learned a lot about UI in Cinema 4D from this post, thank you very much.

Thank you @m_magalhaes! I needed to open the plugins.sln solution instead of the project file. I feel like I've learned something, but I'm not sure what