I'm in a rush and very tired as I'm writing this, please excuse typos.:P
I've been messing around with finding a way to determine if the mouse is inside the window, using only functions provided by Allegro 4.20 to keep it system-independent.
Using windows api functions this test would be a five liner as AJ told me,
however, I clubbed together a small test application to demonstrate the purely Allegro dependant method, which uses the mouse mickeys reported by allegro to keep track of an absolute mouse position that can get negative or larger than the screen dimensions, thus providing the base for checking if the mouse is inside or outside the window.
Problems follow after the codebox...
mouseintest.cpp
...now the problems here are:
This test app sometimes freezes and I can't seem to find why. Anyone have an idea?
(this especially likes to happen when the window is being moved around)
I don't think the freezing has got anything to do with the method of updating the global mouse variables here, as I'm already using this method in another app, where it works fine and the only difference to that other app is that i'm not using that usual "timer logic to keep it running same speed everywhere"(as mentioned in allegros docs) there. So I assume, I'm doing something wrong about the timer.
The other problem is that this method so far has only been tested by me to report the mouse to be outside of the window correctly in Windows, since I don't have access to any other OSes, so it would be nice, if you could test it in the other OSes supported by Allegro, so we can see if it is a usable solution or just an ugly hack.
(Actually it would still be quite an ugly hack, even if it worked...)
I clubbed together a small test application to demonstrate the purely Allegro dependant method, which uses the mouse mickeys reported by allegro to keep track of an absolute mouse position that can get negative or larger than the screen dimensions, thus providing the base for checking if the mouse is inside or outside the window.
This is unreliable because it relies on the programme receiving mouse events after the mouse has left the client window. This is not true in X11, for instance (actually, the situation there is more complicated: if you use mouse mickeys under X11, the mouse is trapped inside the client window and cannot be pulled out of it, unless you use a hardware cursor, in which case the behavior is as I said above).
There is no reliable way of detecting wether or not the window has mouse focus using just Allegro.
There is no reliable way of detecting wether or not the window has mouse focus using just Allegro.
Is this in the plans for future allegro versions?
This is unreliable because it relies on the programme receiving mouse events after the mouse has left the client window. This is not true in X11, for instance[..]
Ok that makes this method practically useless.:(
Now I would also appreciate it, if a check for that would get included in a future version of Allegro, so i'm posting the Windows specific solution here, which AJ gave me:
bool win_mouse_in_window() { POINT mp; RECT wr; GetCursorPos(&mp); GetWindowRect(win_get_window(),&wr); if( (mp.x<wr.left)||(mp.x>wr.right)||(mp.y<wr.top)||(mp.y>wr.bottom) ) return false; else return true; }
I think someone (Andrei?) already posted a patch for that several weeks ago.
A patch that fixes the mouse trapping in X11 and corrects the mickey reporting or a patch that provides a function to check if the mouse is inside the window?
Ummm... I never made such a patch . Although I agree that it would be nice if there was a function for reporting if the mouse was inside or outside the window, or even better, if it was to the left/right/top/bottom of the window. Better still, there could be a second version of te mouse_x and mouse_y variables that store the mouse position relative to the screen bitmap's origin. These variables would be negative if left/top of the window. If the mouse is inside the window, these would be equal to mouse_[x|y]. However, these new variables should be separate from mouse_x and mouse_y in order to maintain backwards compatibility - there's plenty of code out there that assume that the values reurtned by mouse_[x|y] are on-screen, positive, etc.
AE.
I didn't actaully test that code i gave you Dennis, but am fairly confident it will work, i'd test it before any final commits.
I tested it AJ (after reading the WinAPI docs and changing GetClientRect to GetWindowRect ) and it works.
However, I don't know how to make patches for Allegro or how to commit anything and I also have no idea as to where in the code this should be inserted.
I'm currently reading the SVN documentation on sourceforge...
That aside, this function is still useless if noone writes equivalent functions for the other OSes.
It might need some fullscreen/windowed mode test also.
Im sure we can find someone to commit it for you, thats not a concern.
Surely there is someone that wants to make the linux equivalent ?
Anyone ?
Allegro already has "is_windowed_mode()".
In fullscreen mode the windowrectangle would be the full screen and the cursor position would be limited to the full screen anyway, so the function should only be used when is_windowed_mode reports true.
Considering what Andrei said though, maybe there should just be two other functions to allow for greater flexibility:
One that returns the window rectangle in screen(not allegros screen) coordinates and
One that returns the cursor position in screen(not allegros screen) coordinates.
A patch that fixes the mouse trapping in X11 and corrects the mickey reporting
There's nothing to fix. It works as it does by design (to get an infinate range of mickeys).
a patch that provides a function to check if the mouse is inside the window?
This one. If it wasn't Andrei, I'm sure it was someone else.
One that returns the window rectangle in screen(not allegros screen) coordinates and
One that returns the cursor position in screen(not allegros screen) coordinates.
I don't think you can do this reliably everywhere. Having a function that tells you if your application has mouse focus should be enough.
However: if this requires vtable changes, it will not go into 4.2.1 and it's something for 4.3.
My assumption would be that every windowingsystem has some way of retrieving the window position in screen coordinates and the mouse cursor as well, because otherwise I can't imagine how a windowingsystem would ever be able to tell which window is getting the focus.
For my current application I only need to know whether the mouse is in or not, but knowing those other values could be useful.(e.g. for a fun app like Xeyes, which is a small pair of eyes in a window that always looks at the mouse cursor)
For now I'm going to use the windows specific solution with conditional compiling to not break the code for other platforms. Will wait for version 4.2.1 for a true solution.