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.
Glenn Maynard