Win32 org_lwjgl_input_Mouse.getScreenClientRect() question

[rgrzywinski]

I'm in currently trying to decouple Display and Mouse -- specifically "display_hwnd" and "clientSize".  "display_hwnd" is not much of a problem, but "clientSize" currently is.

"clientSize" is used in Mouse.cpp:getScreenClientRect().  Some smart person wrote the two lines:  

clientRect->top = -clientSize.top + windowRect->top;
clientRect->left = -clientSize.left + windowRect->left;

Unfortunately, this smart person felt the need to keep the reason a secret.  Why?  I don't know.  Programmers like to keep secrets, I guess.  Whoever wrote this knew why it was necessary at the time and could have jotted it down to help future generations but I digress.

From org_lwjgl_input_Display.cpp we see that:

// If we're not a fullscreen window, adjust the height to account for the
// height of the title bar (unless undecorated)
clientSize.bottom = height;
clientSize.left = 0;
clientSize.right = width;
clientSize.top = 0;
	
AdjustWindowRectEx(
  &clientSize,    // client-rectangle structure
  windowflags,    // window styles
  FALSE,       // menu-present option
  exstyle   // extended window style
);

(Yay!  A comment!)  where "height" and "width" are the user desired values for the client area (the drawing area).  AdjustWindowRectEx(), as I understand it, changes "clientSize" such that it includes any window decorations.  To me, "clientSize" is now GetWindowRect() but given Display.cpp:getGDICursorDelta() it doesn't seem that it can be.  Any help here would be appreciated.

I thought that I would just T&E (trial and error) this problem out of existance so I turned to MouseTest to get a baseline of current functionality and I noticed the following:

dx=0, dy=0  |  dx=a, dy=0  |  dx=0, dy=0
x=0,  y=h   |   x=i,  y=h  |   x=w,  y=h
------------+--------------+------------
dx=0, dy=b  |  dx=a, dy=b  |  dx=0, dy=b
x=0,  y=j   |   x=i,  y=j  |   x=w,  y=j
------------+--------------+------------
dx=0, dy=0  |  dx=a, dy=0  |  dx=0, dy=0
x=0,  y=0   |   x=i,  y=0  |   x=w,  y=h

where "h" is the height - 1, "w" is the width - 1, "a", "b" and "i", "j" are non-zero values and "0" means never non-zero when the mouse is moved in the quadrant.  It appears that "dx", "dy" and "x", "y" are only defined within the bounds of the window (which is fine -- but it's not doc'd this way).  

The long and the short of this is that I can't "fix" (i.e. remove "clientSize" from) Mouse.cpp:getScreenClientRect() until I know what the expected behavior of Mouse.getX(), .getY(), .getDX() and .getDY() are in a windowed situation.

[elias]

The smart person is me :oops: I'm so smart I can just skip the comments, you know. And I'm pretty sure clientSize is simply a bug, if it can be omitted without consequence on the final result. In any case, I don't know why it was necessary, only that I had my share of troubles getting the cursor position mapped from the useless screen coordinates to window coordinates.

getDX(), getDY(), getX() and getY() are only defined in the window area when the native cursor is enabled as you said. If the native cursor is not enabled, the getX() and getY() are only defined inside the window, but the getDX() and getDY() are unbounded.

- elias

[elias]

I'll take a look at it, probably today. I'm sorry that it has caused you grief :-). You're always welcome to bug me at my elias_naurNOSPAM@hotmail.com MSN account or per email if something is bugging you some other time.

- elias

[rgrzywinski]

No grief given.  It's just limiting the amount of work that gets done in the limited time that I have.  I want to contribute but I keep hitting these roadblocks that don't necessarily have to be there.  Bugs are one thing -- we all have bugs -- but when I keep tripping over code that could be so much clearer with just a few extra comments, well, I start to get angry and wonder why I'm wasting my time.

Anywho, thanks for all your hard work and your responsiveness on these questions.  I'll hopefully get some time later in the week to take a poke at all of this again.

What's funny is that I still don't know if all of this will work with SWT.  I had some cursor fighting with JInput and SWT (SWT would keep taking over the mouse) but JInput uses a dummy window for direct input.  I figured that since LWJGL uses the window that I'm working with, there would be no fighting (since the cooperation (SetCooperativeLevel) would be set).  Only time will tell!

[rgrzywinski]

It turns out that "clientSize" is negative for top and left if there are window decorations -- go figure!

May I suggest that you use MapWindowPoints() (where "hWndTo" would be "0" (implying the desktop)) or ClientToScreen() so that all of this transformation stuff is handed back to windows to get correct.

[elias]

The global clientRect is gone now, and the function has been heavily simplified.

- elias

[elias]

And even more so now, using your suggestions. The cursorPos is now in client local coordinates instead.

- elias

[rgrzywinski]

Rock on!  I'll take a peek in the morning and see what else I can uncover