I have created yet another thread regarding this topic as I didn't want to interfere with existing threads:
This one however isn't really about bringing up a problem and asking for a solution, or workaround or whatever. This here is just to point out my experience and findings, hoping it can help others ... without them having to go through all sorts of trial and testing before getting the big picture.
I have been using a simple CommandData as plugin, which is assigned a short-cut (ctrl-t) to activate. On execution of the plugin a dialog is positioned at the current mouse position ... or that is the intention. Call the plugin again and the dialog will be removed.
class MyCommand : public CommandData
virtual Bool Execute(BaseDocument* doc);
Bool MyCommand::Execute(BaseDocument* doc)
if (GetInputState(BFM_INPUT_MOUSE, BFM_INPUT_MOUSELEFT, bc))
const Int32 mx = bc.GetInt32(BFM_INPUT_X);
const Int32 my = bc.GetInt32(BFM_INPUT_Y);
const Int32 w = 50;
const Int32 h = 50;
mDlg.Open(DLG_TYPE::ASYNC_POPUPEDIT, TEST_COMMAND_PLUGIN_ID, mx, my, w, h, 0);
One would expect that the dialog would be positioned exactly at the current mouse position ...
Following is a screenshot showing the result of activating the plugin when Cinema4D is in fullscreen, and when windowed. It clearly shows that the obtained mouse coordinates, used to position the dialog, are relative to one point, while the positioning of the dialog itself uses a different origin.
Obviously, it would make more sense that both coordinate system uses the same origin ... but I guess that would make things just too simple.