[no subject]

At this point if the mouse corresponds to a valid object's area in
the main menu (in that case it's object id=3D16 "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 >=3D 0 && dlg[current_object].type =3D=3D=20
SGSCROLLBAR) {
....
}

But current_object refers to an object in main menu, while dlg not=20
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



------=_Part_0_1118276576.1435437044665
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii

Hi, no problem, I found the cause for this and have a patch I will commit soon.<br>
Nicolas<div class='profimail-signature'><br></div><br><br><div class='profimail-cite-prefix'>Le 27 juin 2015 22:13, Thomas Huth a &#233;crit:<br></div><blockquote type='cite'>Am Wed, 24 Jun 2015 20:28:00 +0200<br>
schrieb Nicolas Pomar&#232;de &lt;npomarede@xxxxxxxxxxxx&gt;:<br>
<br>

<blockquote type='cite'>
Le 24/06/2015 09:24, Nicolas Pomar&#232;de a &#233;crit :<br>

<blockquote type='cite'>
as stated above, this is random ; my change should require a reset,<br>
so the confirmation dialog not showing depending on where I clicked<br>
in the "Prefetch mode, slower" text is a bug.<br>

</blockquote>
<br>
Here's how I can reproduce it on every try ; it looks random at<br>
first, but in fact it's because it depends on the X location of the<br>
mouse when clicking "Prefetch mode, slower"<br>
<br>
- compile hatari with winuae cpu (to have more options in the system<br>
dialog)<br>
- remove hatari.cfg so that hatari will start with its default values<br>
- run for example : hatari --tos tos404.img --machine falcon<br>
- press F12, go into system dialog<br>
- default is that "prefetch mode" is selected<br>
- click on the "c" in the text "prefetch mode", this will disable <br>
prefetch mode<br>
- now, without moving the mouse, press "enter"<br>
- you go back to the main menu, notice that since the mouse was above <br>
the "c" of "prefetch mode", it is now above the "no reset" object<br>
- press "enter" again to exit main menu<br>
<br>
- we go back to emulation, but there was no "you need to reset" dialog<br>
<br>
repeat above steps, but click on the "p" of "prefetch mode" to<br>
disable it, press "enter" twice and now the dialog "you need to<br>
reset" should appear.<br>
<br>