it was used by MoveRowAbsolute. Refactor: MoveRowAbsolute sets
directly, ignoring whether a row is disabled (if you say "select
row 3", you mean it). MoveRowRelative checks disabled rows,
with logic pulled from MenuUpDown (slightly refactored). That
way, the disabled-row logic affects all relative movement. (Net
simplification.)
that only makes sense if the function was called as the result
of the user pressing a key. ScreenOptionsEditCourse, etc.
use MoveRowAbsolute to set the default row, which calls MoveRowRelative,
causing an extranneous sound.
function named "UpdateEnabledDisabled" to do this, and we
don't need to delay it anymore as GetWidthXY says (that was
before we moved the text into a frame).
have been triggered by something that just played a sound,
or the screen might want to play a different sound. It's
not SM_BeginFadingOut's job to play a sound.
(fixes double-start sound when "next screen" options are
selected from context menus in ScreenOptionsManage*)
(this stuff looks like overzealous abstraction, but I think most of it used to
be more complicated code that was moved off into other classes, and the
stubs were left behind)
ScreenOptionsMaster (and ScreenOptionsManageProfiles).
Make it owned by OptionRow; the only pointer to them
is where they're stored in the OptionRow. This
eliminates the remaining association between m_OptionRowHandlers
and m_pRows; that was confusing, because they're in
different places, and aren't always the same size. It
also simplifies using OptionRowHandlers.
The NextScreen metric would have to be blank, and there aren't any
blank NextScreen metrics.
Move this handling into SM_BeginFadingOut itself. Handle the case
of a blank NextScreen with a warning.
Actually, this changed behavior a little, if a screen was in NAV_THREE_KEY_MENU
and used SELECT_MULTIPLE rows. That combination doesn't make much sense,
though; you'd have to press start on MULTIPLE rows and right on SELECT_ONE
rows. That NAV mode is meant for SELECT_NONE.
we'd set bEndThisScreen to false and continue on. Instead, if we
were going to set a new screen, but stopped because we're transitioning
or the button was a repeat, just ignore it. This eliminates an obscure
code path.
they're accessible by SOptions now, too. Move this slightly
tricky next-screen logic into SOptions, since it can apply
to any screen that sets OptionRowHandlers.
(Actually, this doesn't really belong in BeginFadingOut, since
it's not called "MaybeBeginFadingOutDependingOnTheCurrentOption".
Maybe this should be done in ExportOptions, I'm not sure yet,
but this is a step in the right direction.)
Glenn Maynard