achrist@easystreet.com wrote:
It's one thing to use these on output (like the Windows tray
control) where the user has many ways to infer the meaning
(most users will have some external clues about whether it is
noon or midnight),
(To exactly what context are you referring in this particular
instance? I don't see any obvious context there...)
[...]
and another thing to expect the user to know how to use them
correctly without such context supplied. The wxTimeCtrl
could give the user a little contextual clue if the spin
button on minutes would roll to the previous or next hour
when spun down past zero or up past 59, but it doesn't.
Actually, it *does* do this if the currently selected cell
is the hour; either the up/down arrows or the spin button will
then change the am/pm as one cycles through the hours of the day.
However, while I considered doing this whenever any cell was
selected, I felt that if one was manipulating the minutes or
seconds fields, then the am/pm-ness of the time should not change.
It is a time *entry* control, and my sense was that users would
find it extremely annoying if the hour changed just because you
incremented the minutes or seconds through 0. (Ever tried to set
an old digital clock and accidently miss the time desired, and
have to roll all the way around again?) Also, my sense was that
people were unlikely to notice that the time had suddenly changed
by 12 hours unless they were manipulating the hour, and so end up
with the "wrong time selected/entered" by accident.
So I opted for a field-by-field manipulation strategy: If you're
setting the hour, it does what you want; if you're adjusting the
minute, that's all that changes. I still think this was the right
decision from a human-factors point of view.
/Will Sadkin
Parlance Corporation
www.nameconnector.com