Hi, without further feedback, we will consider this thread as solved by tomorrow and flag it accordingly. Cheers, Ferdinand

Hi, without further feedback, we will consider this thread as solved by tomorrow and flag it accordingly. Cheers, Ferdinand

Hi, without further feedback, we will consider this thread as solved by tomorrow and flag it accordingly. Cheers, Ferdinand

@zipit I just read this（Connect C4D with Tkinter） post，It does seem to help me Thank you again！

Hi @lasselauch, we talked about your problem this morning. There are two ways of looking at your question: You are interested in the event of a closing document (i.e. present progressive) and you want to react to that event by making some changes before this process is finalized (i.e. the document closed). As already stated yesterday by me, there is currently no way to do that in a GeDialog. You will need some kind of node for that. It is also noteworthy that currently CommandData is bugged in this regard in Python. As @mp5gosu already pointed out, MessageData is a really good way to go, unless you do not have already something like TagData plugin where you could squeeze in that functionality. You are interested in the state of the loaded documents list, i.e. if a document has closed (past tense), but not exactly when it happens. This is possible in a dialog. You already provided your own answer here (thanks for making it visible to everyone). The basic idea is just to build some hashmap/list to compare against what Cinema considers to be loaded documents. As an added note, you might want to look at GeDialog.Timer, which will let you execute things in fixed intervals, in order to get closer to the point of when something happened. This won't be to much of a performance strain if implemented carefully. Cheers, Ferdinand

I totally understand. Just wanted to know if it maybe points to something terribly dangerous. I'll just ignore it, then Cheers, Frank

Thanks a lot !!!. I will try it in the next days. I'm free for my personal projects only during weekends

@m_adam Thanks for that extra info. I had done a search in the documentation regarding DrawTexture but didn't see it listed in the API changes. Hence, I didn't expect its behaviour to have changed so drastically. I haven't worked with S22 nor R23 before, so I didn't look in detail about the DrawTexture documentation, since it wasn't listed as changed. May I encourage this to be added in API Changes ... as it is quite a big deal encountering this issue when all worked fine in R16 upto R21.

Hi Manuel, thanks for getting back to me! The size of the bitmap you want to display ? It's 320x116 pixels. Do you want to bitmap to scale when you scale the GeDialog ? No. I rather want the dialog to be just wide enough to fit the bitmap in it. And that seems to happen automatically. Even if I open the dialog with a width of e.g. 100 px, it doesn't get any smaller than (width_of_bitmap + strange_gap * 2). Is it possible that it's a macOS-only issue? Maybe it's the radius of the windows' round corners that gets added to the size. Anyway, maybe this issue isn't worth spending more of your time on. Since it works with a ASYNC_POPUPEDIT style dialog, I think I can live with what I got.

Hi @pyr, thank you for reaching out to us. I am afraid we will need a little bit more than that, as otherwise it will be very hard to answer your question What kind of plugin do you implement? What does it do or what would you consider as running? On a very abstract level you cannot really prevent plugins from running other than not registering them at the start of the application. But you can of course modify their output depending on basically everything, including render events and at what time offset some given document is. Cheers, Ferdinand

Hi @Crea, thank you for reaching out to us. Unfortunately I am a bit slow again this morning, so I have trouble understanding your posting. What do you mean by a real scale value? The size of the bounding box of an object? It also not quite clear to me what you are trying to achieve: a. Reset the scaling component of the transforms of the objects you did previously scale up. b. Or so to speak "reset" the scaling of the children of these objects - so that they "take on" their original size, while the scaling and size of their parent remains modified? Your script seems to work fine for me, but then again I am not quite clear on what you are trying to do. What confuses me the most is that the selected object in your screen is not in a child-parent relation and also the fact that scaling a parent will not change the relative transform of its children, i.e. their local matrix, i.e. what you are seeing the coordinates tab of the attribute manager. Sorry for all the confusion, but we would apricate it if you would clarify some points. Cheers, Ferdinand

@m_adam thanks for R23.110 C4DPYTHONPATH37 !

Scary 🥶 If the objects are already being displayed in the viewport, I don't see why their caches should be rebuilt, just to zoom on the objects (especially when using "O" to zoom on just one single object). Also, properly programmed generator objects should return their bounding box in BaseObject::GetRad() and BaseObject::GetMp(). As far as I see the zooming behavior with "O", only the bounding box is used anyway, so the cache shouldn't even be required for this. That's a pity. But thanks for the answer! Cheers, Frank

Thanks!

@zipit @lasselauch thank you both for your time and knowledge!

@Cairyn Thank you for your reply. The "odd result" it's means the scene is empty , no objects were generated. According to your explanation, I have solved the problem. And it's just an exercise code. Thank you again !

@m_adam Thanks for the clarification. Regards, Georgi.

Hi @mogh, thanks, but I will probably only have a chance to look at it tomorrow. Happy coding and rendering in the mean time Cheers, Ferdinand

Hi, ten times slower sounds rough. It is probably because I was a bit lazy and used a lookup table (visited) to traverse the scene-graph, which is a rather expensive thing to do. Feel free to use the fixed traversal if performance becomes an issue here. Cheers, Ferdinand

Python plugins do not work reliably in R23 on OSX 10.13.6. The C4D minimum spec is for 10.14.6 as Riccardo mentioned. And even if you try to debug a plugin on 10.13.6 what you will notice is that many calls (such as print) don't even work on this OS. So you can't even write anything out to the console to see what the problem might be. No amount of re-installing C4D will help you at all. You just have to let your customers know that the minimum spec for R23 is 10.14.6 and not guarantee any support for anything below that spec.