@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 a lot @zipit . I indeed agree and will update the documentation accordingly. Best and stay safe! R

@m_magalhaes Thank you for this workaround. I hope to see that bug fixed soon! It seems like one that would affect many scripts & plugins.

hi, I think you have access to the beta and BL so you can create a suggestion Cheers, Manuel

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