Re: [hatari-devel] Big bug in the SDL UI

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Am Wed, 24 Jun 2015 20:28:00 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 24/06/2015 09:24, Nicolas Pomarède a écrit :
> > as stated above, this is random ; my change should require a reset,
> > so the confirmation dialog not showing depending on where I clicked
> > in the "Prefetch mode, slower" text is a bug.
> 
> Here's how I can reproduce it on every try ; it looks random at
> first, but in fact it's because it depends on the X location of the
> mouse when clicking "Prefetch mode, slower"
> 
> - compile hatari with winuae cpu (to have more options in the system
> dialog)
> - remove hatari.cfg so that hatari will start with its default values
> - run for example : hatari --tos tos404.img --machine falcon
> - press F12, go into system dialog
> - default is that "prefetch mode" is selected
> - click on the "c" in the text "prefetch mode", this will disable 
> prefetch mode
> - now, without moving the mouse, press "enter"
> - you go back to the main menu, notice that since the mouse was above 
> the "c" of "prefetch mode", it is now above the "no reset" object
> - press "enter" again to exit main menu
> 
> - we go back to emulation, but there was no "you need to reset" dialog
> 
> repeat above steps, but click on the "p" of "prefetch mode" to
> disable it, press "enter" twice and now the dialog "you need to
> reset" should appear.
> 
>  From what I see, the problem happens when the system dialog is
> closed and we redraw the main menu.
> 
> At this point if the mouse corresponds to a valid object's area in
> the main menu (in that case it's object id=16 "No Reset") then if we
> click on "OK" or press enter, the main menu will keep "16" as the
> object that was selected, instead of returning 0. So current_object
> becomes 16. Then the main menu call the dialog for "you need to
> reset", but as current_object is >0 (ie 16) when this dialog is
> called, this is interpreted as if the user canceled, without even
> drawing the dialog.
> 
> This will do this part of the if in SDLGui_DoDialog
>          if (current_object >= 0 && dlg[current_object].type == 
> SGSCROLLBAR) {
>            ...
>          }
> 
> But current_object refers to an object in main menu, while dlg not 
> refers to the new dialog menu we want to draw (the "you need to
> reset" dialog), so this doesn't make sense.
> 
> So I wonder, why does current_object keeps its value between
> different dialogs ? From what I see, it should be set to 0 (or -1)
> when a new dialog opens in SDLGui_DoDialog(), is there a case where
> we want current_object to be propagated between different dialog as
> it is now ?

Sorry, I currently don't have much time to look into this issue and
it's been a while since I worked with that code and my memory might
fail, but IIRC this current_object stuff might be necessary for objects
with the SG_TOUCHEXIT flag. I don't recall it, but there was a reason
that the GUI had to remember the object that caused an touch-exit
event. So it's likely ok to reset this variable to 0 or -1 - unless it
currently points to a touch-exit object, I guess.

 Thomas



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