@m_adam wow! I did what you say,it works!! you are so cool!! thank you very much!!! yeah!!

Thanks a lot Daniel for following up here. Glad to listen that the update actually fixed it, although even on 20.030 I had no better luck to reproduce. Best, Riccardo

@s_bach i see. thx, nevertheless. well, as said, the only way to avoid that collision seems to be: put the plugins into the plugin-folder of the main application. while discussing the other part of my problem (see symbolcache-topic) on other forums (the german c4dnetwork, that is), it became apparent, that other ppl also do have those collision-messages with r20 - and they, too, do not experience those plugins to be not working. if at any time this "problem" should become of interest for you, let me know, if there's something that i could do/deliver/add any detail, to support you in your efforts. cheers, mesut.

I am still a C++ dinosaur, and particularly not experienced with the move operator. So thanks for pointing out the need for the manually written assignment operator. Together with the already implemented move constructor I had, I now more clearly see the point.

Thanks for the confirmation SNHookClass still using the legacy String.

Hi @m_adam! Thank you for your response. I looked for a way to mark the post as a question while submitting, I didn't think to look at the submitted post again for that option. I'll remember next time. KillDocument and Exiting were never ment to run consecutively, they were just two things I wanted to try for different scenarios. I should have clarified that. StopAllThreads() unfortunately wasn't enough, but adding in a small message plugin to trigger the exit from the CoreMessage() did the trick. I'm now changing a global boolean for the CoreMessage() to look for. Is that what you had in mind? Thank you for your help, everything works now. I'll make sure and try and find the "mark as solved" button on my way out Edit: I can't actually mark your comment as the solution, only this one...

Thanks a lot @C4DS @m_adam ! So I think it's better to create separate CommandDataplugins to perform the same action of each button, it's less complicated and allow the user to change the keyboard shortcuts and exclude the need of the GUI being always open. Although the m_adam suggestions may be useful for other plugins ideas I have. I'll try it later. Thanksss !

Hi Pim, no, I don't think so. Basically the Selection tag reacts to MSG_POINTS_CHANGED and MSG_POLYGONS_CHANGED, in the end adding or removing the needed amount of points or polygons in the selection array. But there's no information, what to do with for example additional points. And so it heavily depends on where the new points/polygons are added and also which tool does so, what the outcome for those selected entities will be. Something that will probably be addressed in future with the CustomDataTag introduced in R20. Cheers, Andreas

Works great, thanks. -Pim

Hi, yes, this is still the "official" way to add separators to the Plugins menu. Cheers, Andreas

Thanks. And yes, I used that value already. -Pim

Thank you so much, that's exactly what I needed! Dan

Thanks, @C4DS for pointing out this issue. It will be fixed in the next version. Cheers, Maxime.

Congrats on the new forum! it is very informative About time

Working as expected now ... didn't think of playing with the PLUGINTYPE_xxx Thanks for details.

Hi Riccardo, I am not sure what you mean, but I guess you mean that you define selection tags on one of the children and use that selection on the resulting objectdata object? -Pim

Hi @Rage I guess export_OBJ example on our Github repository is what you are looking for. Note for the moment values of the BaseContainer are not available in the Python Documentation. But you could find them in the C++ documentation about fobjexport2.h. If you have any question please let me know. Cheers, Maxime.

Hi @C4DS, thanks a lot for your message. Documentation tag have been added. Drag and Drop Manual, changed to: GeDialog Drag and Drop GeUserArea Drag and Drop GUI Message Drag and Drop Links will work correctly in the next update of the doc. However you are right, the code sample in the old manual was wrong. It should have been if (CheckDropArea(DLG_GROUP, msg, true, true)) {} Note, you could also create your own function as demonstrated in the AsyncTest Example. Cheers, Maxime.

Thanks to both of you. I originally thought solution 2 would be the way to go, and have proceeded in that direction ... but the more I look at the result the more I am getting convinced that this wasn't the right approach to deal with the issue. So, I am still open for solution 1. But will try yet another solution, inspired by the reply from WickedP. I intentionally didn't include a solution where I would create iCustomGui / GeUserArea for each separate gadget. As I thought this would result in drag and drop to only work when hovered over the separate gadgets, and failing when mouse would hover over the space between these gadgets. But using a global drag and drop function on the dialog itself (instead of all separate gadgets) will actually provide for a complete solution. EDIT: Set the state of this post to "Solved". In the end I went for a complete different solution. Not using any GeUserArea at all. As such, I could simply position and use EditText the way it was intended.

That's great, Andreas. Thanks! I'll kludge on until then.