Re: [AD] todo.txt

[Andrei Ellman <ae-a-alleg@xxxxxxxxxx>]

Evert Glebbeek wrote:
> These things are listed as 4.2.1 TODO's, can someone confirm or otherwise 
> comment on the ones that I'm not clear on?
>
> [...]
>
> - Investigate mouse problem reported in 
> http://www.allegro.cc/forums/view_thread.php?_id=459972

This was the same problem I reported earlier with the "[AD] Problem with
remove_mouse() and video bitmaps." thread in
http://sourceforge.net/mailarchive/forum.php?thread_id=9338665&forum_id=34598
The 'fix' was to mention in the documentation that if the bitmap with
the mouse on is to be destroyed, then show_mouse(NULL) (or any bitmap
that is not being destroyed) should be called.
(btw. thanks to the recent change in the way allegro.cc uses URLs to
threads, the URL of that thread is now
http://www.allegro.cc/forums/thread/459972 )


> - fix mouse coordinates in GFX_DIRECTX_WIN, [AD] 2005-12-09
>   "Inconsistent behaviour with mouse coordinates in different windowed 
> modes in Windows."
>
> What about this?

See
http://sourceforge.net/mailarchive/forum.php?thread_id=9187761&forum_id=34598
This was something that involved the mouse-coordinates sometimes being
returned as -4096,-4096 in GFX_DIRECTX_WIN (although GFX_GDI acted
normally). However, the version of Allegro I was using at the time
(possibly 4.2.0RC2 or one of the weekly CVS builds -
allegro_20051015.zip) was able to produce this behaviour, but I cannot
reporoduce this with the final version of 4.2.0.

One unusual thing I do notice is that if I run a dynamically linked
version of my program that was built with 4.2.0RC2 (or whatever it was)
using the current DLL, my program still shows this weird behaviour.

Were there any changes made to the Windows mouse code between 4.2.0RC2
and 4.2.0 final? If so, would they have been made in such a way that it
would effect the part of the code that got linked to the app rather than
the part of the code that went in the DLL?

What I could still to is to salvage a version of the sourcecode of my
program from the time, compile with the latest 4.2.0, and see if I was
doing something in my code that could cause this to happen. But if there
have been any significant changes to the mouse-code by 4.2.0 final, then
it's probably the changes that have fixed it.



> - add is_mouse_inside_window() function
>
> Do we want this, or push it to 4.2.2?

Erm. wouldn't adding a new function to the API break ABI compatibility
meaning we'd have to wait until 4.3?

Regardless of this, is_mouse_inside_window() would come in handly - or
even better, a way of finding out if the mouse is left, right, above,
below, etc the window, or better still, an alternative version of
mouse_x and mouse_y that also return the mouse-coordinates relative to
the windowed 'screen' even when the mouse is outside.

Also, there are two other issues worth mentioning. I personally doubt
that they will be fixed in time for 4.2.1, but should at least be
mentined on a TODO list:
http://sourceforge.net/mailarchive/forum.php?thread_id=9486699&forum_id=34598 

- Strange behaviour in the Windows GDI mode in Windows 2000
and
http://sourceforge.net/mailarchive/message.php?msg_id=11975593 - problem
with get_gfx_mode_list()


AE.