FS#7313 - Current menu item not spoken after accepting or cancelling a choice setting

Attached to Project: Rockbox
Opened by James Teh (jteh) - Friday, 15 June 2007, 01:03 GMT
Last edited by Jonathan Gordon (jdgordon) - Thursday, 21 June 2007, 12:33 GMT
Task Type Bugs
Category User Interface
Status Closed
Assigned To No-one
Operating System SW-codec
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


After accepting or cancelling a choice setting, the current menu item (i.e. the name of the setting) is not voiced as it should be. To explain by example:
1. Ensure that voiced menus are enabled.
2. From the main menu, select Settings->General Settings->Bookmarking->Bookmark on stop.
3. Observe that the possible choices are spoken correctly as you move around the menu.
4. Exit the choice without accepting (e.g. press left on the Iriver H300).
5. Observe the return to the Bookmarking settings menu. However, the current option, "Bookmark on stop", is not spoken.
6. Repeat this procedure, but accept the setting in step 4 (e.g. by pressing select) instead of cancelling it. The same observation applies (step 5).
This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Thursday, 21 June 2007, 12:33 GMT
Reason for closing:  Accepted
Comment by James Teh (jteh) - Thursday, 21 June 2007, 02:41 GMT
This patch fixes this bug. The patch also fixes other instances of this bug, such as items like System->Rockbox info which call a function. Additionally, the patch fixes the bug where exiting from a sub-menu of a context menu would speak the parent menu item, even though the menus are exited; e.g. if you enter WPS context menu->Sound settings->Volume then press back, "Sound settings" was spoken, even though pressing back from Volume exits the menus.
Comment by Jonathan Gordon (jdgordon) - Thursday, 21 June 2007, 10:21 GMT
The attached patch hopefully does the same as yours, except I tihnk its a bit cleaner, I havnt tested it because i can grab a voice file atm, so please let me know
Comment by James Teh (jteh) - Thursday, 21 June 2007, 10:48 GMT
Ah. I did consider using a variable like this, but wondered whether it would be less efficient, as the talk_item check has to be done even if there should be no speech.

Your patch does not fix the bug I described above regarding sub-context menus with the MENU_EXITAFTERTHISMENU flag. This patch fixes. (There should be no speech if we are exiting the loop.)