(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