No idea why it does not work out of the box. But you could implement NodeData::GetDParameter() to see if something weird happens there and to set the value yourself. Edit: I just tested the scenario in R20 and with RoundedTube and everything seems to work fine.

Hi, I am not sure if we are talking about the same thing, I meant (as extra lazy pseudo-code). edit: Jeah, just like that. But you could try to give Cinema some time to catch up and invoke an EventAdd() or doc->ExecutePasses between the tool activations. Cheers, zipit

@r_gigante Thanks for your reply! You were absolutely right about checking input type. When i did a simple type check everything started to work as it should!

hi, Well, in that case you have no real way to be 100% sure that the cache of the linked object will be created and updated. CheckDirty is call more often than ModifyObject so between the two I would go with CheckDIrty Another function you could also use, is Execute. By adding it to a real late moment on the scene execution you could maybe make your deformer to update at the end (op->SetDirty()) You could also use a Message where you can check any change on the scene and check if it's your object that have changed. (by storing it's dirtyState) Finally, when the link is modified or when someone drop an object you could check what kind of object it is and change the execute priority accordingly. I think that Execute is probably the best solution here. Cheers, Manuel

Nevermind. Trying to explain will probably lead us too far. I was only wondering if messaging was possible between a CommandData and its GeDialog.

@m_magalhaes No other dependencies. Plugin type is deformer. Yes, i should probably ask it on Redshift forum. Thanks for reply!

@Cairyn Thanks again! That's what I was afraid of, but thanks for the information!

@PluginStudent said in Buggy GeDialog Local2Global and Local2Screen: There is an example of how to use a function in the documentation: GeDialog Manual. Right, I should be more careful with my assumptions. But apparently, no one tried to use Local2Screen outside of GeDialog::Command, as only inside of that method does it return appropriate values. (I tried in GeDialog::CreateLayout and GeDialog::InitValues) As for Local2Global, I cannot get it to return meaningful values outside nor inside GeDialog::Command.

Always using the threadIndex, of course :-) Thanks, I'll try that!

hi, there's nothing more to do in R21/S22, you should maybe post your project to see if there's something wrong. Cheers Manuel

Extra info! While I had set this topic as solved, without an actual WORKING solution being provided, I simply wanted to point out for future reference that R16 - R19 has a slight different behaviour. As with R20 and R21 the first time the dialog is opened it gets positioned centered on the current mouse position. On all subsequent opening it gets positioned with its upper left corner at 0,0. Something got "fixed" between R19 and R20, but not "fixed enough".

@m_magalhaes said in Mouse positions and screen dimensions: But no news :) Thanks for the update. I guess no news is good news ...

Hi @C4DS, just to confirm that there is nothing built-in Cinema 4D. For python most of the library in the end only reroutes through OS call and does have a system dependant call, so you will probably end with something like that also in C++. Cheers, Maxime.

@m_magalhaes said in GeUserArea - RemoveLastCursorInfo not compatible with ActivateFading: ActivateFading is also using RemoveLastCursorInfo internally. I more or less assumed this was the case. As such I went with an alternative solution using RemoveLastCursorInfo to be able to detect the mouse leaving the GeUserArea, while providing an own implementation for fading in and out. Thanks for confirming.

@PluginStudent Yup ... it's official, I need glasses on top of my glasses. Thanks for pointing it out.

But I appreciate that you where trying to make things more streamlined

Sending another CoreMessage... interesting... I will try that, too. Thank you!

@m_adam MODELINGCOMMANDFLAGS::NONE works! Thanks again for helping me out!

@m_magalhaes said in Trigger Tag: I though you were using a hidden BaseLink parameter on your tag to point to the other tag. Ah, didn't think about that. Clever.