Originally Posted by rahanner
I wrote lots of code in the 40 years I worked so I can tell you that you are wrong.
The way it works is like this: some choices are predefined then presented to the user. The response that comes back can only be one of those choices and the value assigned to each one is fixed. There's essentially nothing to do but move forward.
When the input is anything entered in a free form field of any kind, the code that processes it has to parse it to see what's there, check for valid characters, validate the value and validate any constraints on the value. Then if it's not valid, write a whole other code path to present the error with new messages back to the user to retry.
Well, I too
have written lots of code in the 40 years I've
been a programmer, and I don't think I'm wrong!
Here's a way you could do direct numeric entry of hours without ever showing an error message
: on the first digit, accept only 0 or 1. If any other digit is pressed, ignore it. On the second digit, accept 1-9 if the first digit is 0, or 0-2 if the first digit is 1, and ignore "move right" until the second digit is valid.
Minutes are even easier: accept 0-5 for the first digit and 0-9 for the second. Done. (A spinner, radio button, or similar control does make sense to select AM or PM, though.)
But to program a spinner, you have to show the user the starting value, look for the remote codes that signify "+" and "-", add or subtract 1 (for hours) or 5 (for minutes), check for overflow and underflow, and wrap around if necessary.
In practice, though, both techniques will rely on pre-written code modules that do all the hard work. All the application programmer has to do is decide which module to call and pass it the starting, minimum, maximum, (and increment, for a spinner) values.
On the DVR+, we see the direct entry technique used when someone enters a channel number
! That requires a more complex validation against a table, too; but the DVR+ doesn't require the user to "spin" through all possible channels!* So a direct numeric entry module already exists
in the DVR+, and it could have been reused for entering times. But instead, someone chose the spinner module.
Why? I think
is probably close: the programmer thought spinners would be easier for the users, and for minutes, the increment of 5 was chosen so someone didn't have to click the #$%@ remote 30 times to move from 30 down to 0!
The problem with that thinking was, it neglected the need for padding - and on manual recordings, they disabled the "Early" and "Late" padding options, thinking you didn't need them since you'd be setting the time manually anyway! So if you want to pad a manual recording, you're forced to use a full 5 minutes' worth of padding, even if you only need a minute or two.
All of that was forgivable in the 101R firmware release. But I remember complaining about it back in 2014, when I was on 108R, and with CM as the "middleman" between E* and us users, it was never a big enough deal to become a priority for changing.
*Ironically, the iView does
use a spinner for editing the channel number on a recording timer, even though it uses direct numeric entry for the start and end times. And as if to prove my point, they fouled it up! The channel spinner often skips channels or even gets caught in a "loop" of a few channels, making it impossible to select some channels with the spinner!