There is stricter error checking now. You will need to do the following... while (file->ReadChar(&ch)) { iferr(text.AppendChar(ch)) { return; //Handle the error } }

hello @juergenb and thanks for reaching us, You have to use a lock system, we have our Lock Manual with the information you will need. Of course if you have question feel free to ask them. Cheers, Manuel

@mp5gosu thanks for the addition. Cheers, Manuel

hello, fast reply, confirmation it's normal. The name used to select a font on macOS is its postscript font name, hence nothing to do here. On Windows you have to enumerate all fonts to find the right one and get the postscript name of its 'post' table. Cheers, Manuel

Hi, I often use the python generator to create some prototype myself. So it's ok for me. But if you want to give or sell your result, you should move to a plugin. It's not hard at all, if you already did that prototype, the plugin is easy, and we are here in case you have some issue. Nice result :) Cheers, Manuel

Without a further reply from you until tomorrow I will consider and mark this topic as solved, but feel free to open it again if you have more information. Cheers, Maxime.

Hi Maxime, Thank you for the response, we are trying out a few others methods now. :) There is not much confidential, it just comes down to our current queue manager software and workflow methods here, and with that this option from Zipit is not ideal. Thank you very much for all the support guys, I will update this post when we know more. Stay safe!

Hi sorry I overlook your answers, There is no way to directly change the path in the RenderQueue to do so, you have to edit the document. So before adding a document, you need to load them, then define the path in the render setting and then resave the file. Here a quick example. import c4d # Load the document docPath = r"PATHtoc4dFile.c4d" doc = c4d.documents.LoadDocument(docPath, c4d.SCENEFILTER_OBJECTS | c4d.SCENEFILTER_MATERIALS, None) # Retrieves the active render setting renderData = doc.GetActiveRenderData() # Set the new path for the picture renderData[c4d.RDATA_PATH] = r"MyPicturePath.exr" # Save the document c4d.documents.SaveDocument(doc, docPath, c4d.SAVEDOCUMENTFLAGS_DONTADDTORECENTLIST, c4d.FORMAT_C4DEXPORT) Cheers, Maxime.

@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!

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.

hi, as @PluginStudent said i was using GeGetEscTestThread and by the way, it's not really working =) But that's the same question with your code. You test the thread that have been provided to you or your own thread. For that you pass that thread as a reference to the lambda function. Cheers, Manuel

hi, tomorrow, I will consider that thread as solved without further news. Cheers, Manuel

Great, thank you.

hi, must be monday, sorry, the 21.207 IS the current last public version (and after another test, the bug is definitely there). It's already out :) the next update we can't tell what and when. Cheers, Manuel

@m_adam Thank you for the clarification and the code example, Maxime!

Yes, Thanks. :)

@r_gigante Perfect! Worked like a charm. Thank you.

Thanks, it's good to know that there are internal functionalities actually using these flags!

@zipit This plug-in has a twin plug-in that has some properties with the same name, and I suspect that the properties with the same name cause conflicts (even if the ids are different).I made the modification and it is normal now. Thank you for your reply Cheers