Mouse positions and screen dimensions
-
Hi,
I am looking to develop a few plugins and was playing with the mouse position and screen dimensions, as seen in code snippet below.
I have assigned a shortcut to the plugin, which I then use to activate the plugin with different positions of the mouse to trigger theCommandData::Execute
.class MyCommand : public CommandData { public: // R20 // virtual Bool Execute(BaseDocument* doc) // R21 virtual Bool Execute(BaseDocument* doc, GeDialog* parentManager) { BaseContainer bc; 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); ApplicationOutput("Mouse coordinates @, @", mx, my); Int32 sx1, sx2, sy1, sy2; GeGetScreenDimensions(mx, my, true, &sx1, &sy1, &sx2, &sy2); ApplicationOutput("Screen has coordinates @, @ -> @, @", sx1, sy1, sx2, sy2); } return true; } };
I am using a multiple monitor setup for testing purposes, as can be seen in following picture:
The picture isn't that important, but it can help in understanding the next screenshots taken from testing with the above setup.
I have been running R20 and R21 positioned identically relative to the two monitor setup, and have triggered the plugin with specific mouse positions. Notice that the accuracy of the mouse positions between the two tests isn't that important.[ EDIT 1:
Note that the actual locations used for testing out the mouse position aren't important. I had chosen a few locations as references which could be easily reproduced both with R0 and R21.
Therefore, I created two dummy folders on the desktop, which I could use outside of the main window next to some easily recognizable locations on the main window itself.I have indicated the locations with a red dot as I couldn't capture the mouse cursor.
EDIT 1]R20: (had to upload a low quality jpg, better quality png is available on request)
R21: (same as for R20, a low quality jpg is uploaded for reason of allowed upload size)
Summary of the test.
While R20 seems to have appropriate coordinates for mouse positions outside of the main window, the values for R21 do not make any sense.However, both version of Cinema4D seem to provide coordinates relative to some reference point of the main window itself. Move the window onto one screen or another, one would expect coordinates to be different, since with
GetScreenDimensions
the provided coordinates are used to detect the screen dimensions.In R20, when the main window of Cinema4D is entirely positioned inside the right side monitor, and the mouse cursor is positioned in the left side monitor area, executing the provided code results in:
"Screen has coordinates -1080, -650 -> 0, 1270". Which is exactly what one would expect, if the right side monitor is the main monitor with reference corner 0, 0.
However, move the main Cinema4D window into the left monitor area (entirely or only partially), then with the same mouse position as before one will get:
"Screen has coordinates 0, 0 -> 1920, 1080". Which definitely does not make any sense.So, while the implementation for R20 is "slightly" better than R21, both are useless when it comes to multi monitor setups. I have not tested single monitor setup in details as, to me, it is not an option to have this working with single monitor and not working with multi monitors.
[ EDIT 2:
The original purpose for testing out was to find out if I could use some global mouse positioning, and be able to detect if the mouse position was close to the edge of a monitor.
I actually got side-tracked by trying to figure out the resulting mouse coordinates when the main window was on the right and left window. From this side-tracking I got even more confused about mouse coordinates "outside" of the main window. And then got totally off track finding out differences between R20 and R21. So, the whole thread just seems as a one big brain fart. Feel free to request to explain in smaller steps if the above brain dump doesn't make any sense.
EDIT 2 ]Apologies for the lenghty post.
-
Added some edits in the original post, hopefully clarifying some things.
-
Hi,
atleast for me your post was just fine regarding its readability, but it is a very specific topic with very specific requirements. It will probably take some time before you get an answer from MAXON.
Cheers,
zipit -
hi,
Don't worry, it was clear, i had to get an old monitor in my basement to be sure to have a different resolution.
my result are sometimes event more strange. I have on my test two monitors 2560x1440 and one 1920x1200 and sometimes the function return me 5120 (2560x2)
R21 is still able to return negative mouse position but you have to move the mouse fast. (not sure if this come from the more optimise refresh cycle)I'll ask the dev for that one.
Cheers,
Manuel -
Any news on this topic.
I have been able to get something going with R20, on single and multi monitor setup.
But as mentioned earlier the coordinates returned from R21 don't make sense, and are different if the main Cinema application window is full-screen (on primary monitor) or windowed. -
hi,
We asked the dev with all your threads and tests.
@r_gigante made a bunch of tests also.But no news
Cheers,
Manuel -
@m_magalhaes said in Mouse positions and screen dimensions:
But no news
Thanks for the update. I guess no news is good news ...
-
Hi again,
It is not my intention to bump this topic every other day, but I just want to know if a response from devs is still in the pipeline.So far, it seems that with R21 the obtained mouse coordinates are valid as long as the mouse pointer is hovering over the main Cinema application window. Once outside of that window the obtained coordinates are that of the last position inside the window.
This means that when the application is not full screen, or when multiple monitors are involved the coordinates outside of the window are useless. Most important is that one cannot find out if the mouse cursor is inside or outside the window and thus decide (or know) the obtained values are useless.This isn't an issue with R20.
On the other hand, as far as I have understood with the release of S22, there will be no further service packs for R21. Which means any fix to this issue (if provided) will be S22 or R22.
Which brings me to the inevitable decision that I will need to ditch any further development for R21. There just are too many unresolved open issues for any of my current (and work-in-progress) plugins. -
hi,
no problem to bump it.
But still no news.Cheers,
Manuel -
I am starting to lose hope we'll ever say any update/answer on this topic.
And as a result I am close to giving up on further R21 development. And beyond.
For me, there are just too many open issues that don't get resolved (this one included). The cost for finding workarounds, or alternative solutions is just becoming too high, and not worth the effort anymore. -
hi,
I apologie for the delay here.
you will have an answer for sure, maybe not the one you are waiting for, but you will have one.
I was going to talk about that in our daily meeting anyway, but thanks for bumping it again, we asked the dev againCheers,
Manuel -
hi,
After talking with dev and few tests:
- Mouse data could be outdated when you were calling a command Data via a shortcut. This bug will be fixed in the next update.
GetInputState
return coordinate in local to the editor windows space, not in screen space. But this should be used with caution and should probably be used only for keyboard modifier checks.GetScreenDimensions
This was a bit hard to understand what was going on, i must say that i wasn't expecting that.
First, the coordinates are relatives to the main display. (not the 1st display, but the display set as "main").
as the mouse coordinates wasn't really helpfull you can "force them" to 0,0 and -10,-10
This is my setup and the monitor 2 is in fact my main display.
0,0 will return 0,0 / 2560, 1440
-10,-10 will return -491, 2069 / -1440, 0and that does make.
Cheers,
Manuel -
@m_magalhaes said in Mouse positions and screen dimensions:
Thanks for the detailed response.
This bug will be fixed in the next update.
Are we still talking R21, or will this be R22?
GetInputState
return coordinate in local to the editor windows space, not in screen space. But this should be used with caution and should probably be used only for keyboard modifier checks.
If
GetInputSate
is not to be used to obtain the mouse coordinates, what would be the better way to get the mouse position? -
@C4DS said in Mouse positions and screen dimensions:
Are we still talking R21, or will this be R22?
it's not a stop seller so it will be probably fixed in R23.
Well this is the global function, in a GeDialog you should use GeDialog::GetInputState
I need to check the real differences to answer with more details sorry. This is something we need to talk about and document a bit more.
Not the answer you were waiting for i know.
Cheers,
Manuel -
it's not a stop seller so it will be probably fixed in R23.
Oh, I read "the next update" as being "the update right around the corner".
Not as if someone saying "the next day" but actually meaning "in a not to near future".
But thanks for pointing it out.Well this is the global function, in a GeDialog you should use
GeDialog::GetInputState
Sorry, I am not in context of a
GeDialog
, but aCommandData
.
What other options than the global function do I have here?True, not really the answer I was looking for, but still grateful for the reply. Thank you for that.
-
@m_magalhaes said in Mouse positions and screen dimensions:
I need to check the real differences to answer with more details sorry. This is something we need to talk about and document a bit more.
Any news or additional info to share on this?
-
hi,
sorry, it get out of my mind.
Cheers,
Manuel