Ok, i solved my problem was my miss. Thanks again.

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

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

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.

Yes, Thanks.

Thanks Both of you @zipit @m_adam , Quote: "keep in mind coping data is expensive" I had the feeling that the very nice example I am building on has some limitations (speed) as you mentioned. I guess I have to re organice this section (selecting points) and clean up. My aproach as a beginner is more or less like this. try get it to work anyhow try to understand it by cleaning try to make a compact function so it doesn't break my code everytime i touch it ... I have an old C++ code as an cheat sheet to get a general idea how a perfomant code could look like (selecting & working just inside one big point object list, as far as I understand it) , but at this stage I can't combine them jet hence the different selecting aproach. Anyway I try to get somethingmore robust ... Thank you for your time. mogh

Hi Index, thanks for reaching out us. I confirm that the development is on supporting glTF is continuing. Stay tuned! Best, R

thank you so much!!

@PluginStudent Thank you.

@r_gigante While doing some code cleanup to add new features to a plugin, I noticed some comments regarding this particular topic. The comment mentioned the need for a workaround since the Blit() functionality on Windows was faulty. Problem with Blit() and MultipassBitmap still occurs after switching to Visual Studio 2017, Windows 10, running R20.059

I don't think there are any official "tools". But the docs describe how to handle unicode (Dialog Layout The encoding is 7-bit ASCII with other characters encoded as \uHHHH. For example 'Natürlich' is written 'Nat\u00fcrlich'. Byte-order marks are not used.

@m_magalhaes Thank you

Hi @blastframe unfortunately for the moment is not possible to implement its own logger in python. However, you could use any existing loggers. Here an example that writes into the Application (Default) Logger. import maxon txt = "My Wonderfull Text" defaultLogger = maxon.Loggers.Default() defaultLogger.Write(maxon.TARGETAUDIENCE.ALL, txt, maxon.MAXON_SOURCE_LOCATION(1), maxon.WRITEMETA.DEFAULT) Note that the print simply reroutes to the Python logger. But it can be useful to directly use the logger to write if you pass the write meta maxon.WRITEMETA.UI_SYNC_DRAW this way you can force a redraw of the console (slower) after each print, this can be used to avoid the limitation mentioned in the second part of this post. Cheers, Maxime

@PluginStudent Thanks for the idea of how to solve this! I was doing what you described before posting my example, but probably making it too complicated. The documentation for the Link gadget describes the pointer LINKBOX_ACCEPT_MESSAGE_ACCEPT as 'A pointer to a boolean value. Set this value to true to accept the object.' so that sounded like what I needed. I've rewritten the approach you described and have it seemingly working.

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

Great, thank you.

hello, I'will consider this thread as solved tomorrow if you have nothing to add Cheers, Manuel

Since this topic is older than a week I marked is as closed, but feel free to reopen it if you have further questions. Cheers, Maxime

Hi @chakuew0, plugincafe is only a support for Cinema 4D API and SDK, and I don't see in any way how your question is related to the API, but more an issue within Cinema 4D. So please contact the Cinema 4D support for all no related API questions in this page. Cheers, Maxime.