Bugzilla – Bug 514
Difficulty editing entered text
Last modified: 2009-09-08 09:14:33 UTC
If you are doing a search for, say, ABC and enter ACD, scrolling backwards to change the C requires you to place the cursor under the C and then wait a couple of seconds. If you try instantly when the cursor is under C, you add a third letter back. If you move back so the cursor is under the A then it changes the A rather than the C. ACD <left> AC (C underlined) <2> (for a B) gives ACB but ACD <left> AC (C underlined) - wait for 2 seconds - <2> (for a B) gives AB It's a pain having a delay to edit the text. And inconsistent as there is seemingly no delay with the first letter.
Chris, if you use the press-and-hold-PLAY to save a playlist, does that text entry work better for you? Search uses its own entry routines, but SavePlaylist uses the INPUT.Text mode. Search should eventually make use of this as well, so feedback on that would be useful too.
Umm, better in that the behaviour I mentioned doesn't occur - but the playlist entry system (which I've never used before) seems to have a whole bunch of its own quirks: Pressing on the right arrow changes the text to capitals .. plus arrow signs keep appearing in the middle of the words.
wow, I've not seen that one before. Pressing right should jump to the screen confirming the save. Do you have the latest nightly, and are using Press-AND-Hold PLAY from teh now playing screen? Make sure you do NOT have the SavePlaylist plugin as that is obsoleted by this feature. I've converted the Search functions to use the INPUT.Text mode so tomorrow's nightly will be good for testing the search functions for any issues that you have.
Yep, this is the latest nightly. Try entering the band abba 2 <right> 2 2 <right> 2 2 <right> 2 <right> gives acBC->
I end up with abba->, using the current CVS with my patch. so, I'm not sure what is happening there. I had an old SavePlaylistPlus plugin that used to change case on ADD. Please try out tomorrow's nightly and we'll see what happens from there.
looks like this is actually a problem in Common::numberLetter. There is a 1 second timer that resets to the first letter for a given button. Even pressing right, the routine still compares to the last letter for the 'displayTextTimeout'. hope to have a fix shortly.
added $client->lastLetterTime(0); to the 'nextChar' function in INPUT.Text. This should result in the following: 2 <right> 2 2 = ab (instead of the ac that has been reported) try this out in the Sept 1 nightly and let me know if there are any other issues.
Hi, This is much better than it was, I've only found one small problem so far. When you're moving right everything seems fine, but the timer for input isn't reset when you move left. If I'm trying for abba (again!), but I make a mistake forwards, when I go back to edit it continues from the incorrect letter instead of resetting. 2 <right> 2 2 <right> 2 2 2 <right>: abc (oops, meant abb - so ...) <left> 2 2: I'd expect abb, but instead get abA You have to be reasonably quick to see the problem I'll admit - but all the text messaging we do in the UK makes me pretty speedy with the remote.
thanks. fixed that for sept 2. Please mark this as fixed if it works properly for you.
That seems fine now, thanks.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.