Re: [AD] Don't use Devpaks

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Tue 10 May 2016 09:47:10 AM Andrew Robinson wrote:
> I understand your nightmare, but all hope is not lost. For example, how
> about incorporating show_mouse(NULL) in the destroy_bitmap() function? If
> mouse_init() was never called, and instead of crashing or erroring out,
> just gracefully handle that exception and ignore it, backwards
> compatibility would be retained and the API will make more sense in that
> regard.

Its still a behavior change. Whether its one that will break anything remains 
to be seen.

That said, that isn't and entirely valid change. You'd have to check to see if 
the bitmap being destroyed is the bitmap that is currently the target for the 
mouse. You don't want destroy_bitmap clearing the show_mouse() bitmap every 
time, even if it isn't the target.

> On 5/10/2016 at 8:24 AM, Thomas Fjellstrom <thomas@xxxxxxxxxx> wrote:
> >On Tue 10 May 2016 08:08:33 AM Andrew Robinson wrote:
> >> PS -- The http://www.cppgameprogramming.com mouse example is a perfectly
> >> good example, since if I leave off destroy_bitmap() as they did in their
> >> example, no crash will occur.
> >> 
> >> I've looked at many examples of mouse programming by Allegro users, and I
> >> have yet to see any that use show_mouse(NULL) before using
> >> destroy_bitmap(). This is the community's way of inadvertently giving
> >> feedback to the Allegro developers that the usage of show_mouse(NULL)
> >> before destroy_bitmap() doesn't make sense. No other toolkit does this
> >> type
> >> of thing, so the Allegro developers should eliminate it. So my question
> >> is,
> >> are the Allegro developers listening to their users?
> >
> >They do, but it wasn't actually brought up as an actual issue in the past
> 
> when
> 
> >Allegro 4 was still in development at a stage where incompatible changes
> 
> could
> 
> >be made.
> >
> >Allegro 4 and some Allegro 5 releases made some pretty crazy forwards and
> >backwards compatibility guarantees. We can't just go in and change apis
> 
> willy-
> 
> >nilly, lest it break existing applications.
> 
> _______________________________________________
> Allegro-developers mailing list
> Allegro-developers@xxxxxxxxxx
> https://mail.gna.org/listinfo/allegro-developers

-- 
Thomas Fjellstrom
thomas@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/