fade them in and out at the same time; we do this by tweening the whole
row up and down, and fading each part of the row. This is a big pain,
because we're also tweening each part for other reasons, and these
tweens tend to collide. The whole thing is brittle and complicated,
and it's making fixing other problems a pain.
Try it a little differently: to fade the whole row, tween the alpha
along with the position of the whole row. Then, manually propagate
the changing alpha value to each part, using BaseAlpha, so it doesn't
affect other tweens.
This also helps segregate the fading: with the exception of the actual
propagation, OptionRow doesn't have to know anything about it. Before,
it had to constantly be careful that any tweening operations didn't
collide with the alpha tweening; often, one or the other would be cancelled,
resulting in either the change not happening at all, or snapping instead
of fading.
(This is still a hack, but it's more manageable; it puts control of high-level
tweening entirely in SOptionsMenu's control, instead of half in OptionRow.)
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).
Implement Reload() explicitly, so we can clearly short-
circuit for static rows.
Fix up ScreenOptionsEditCourseEntry (broken during the
course of things).
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.
one we need, and then make copies as needed. This avoids lots of
extra loading (which can be slow, even with refcounted data; lots of path
lookups, etc). (Trying to get this to the point where we can construct new
OptionRows for a menu without making a whole new menu.) This approach
means we don't lose the potential to have different sTypes of OptionRow
in a single menu. (The annoying bit is that any actor we copy has to handle
copying, which is tricky for ActorFrame and doesn't work yet for AutoActor.
Working on it ...)
individually, just load one and copy it for the rest; this avoids doing
the whole "search, read redir, find refcounted" code path for every
option. Don't load data from OptionRow::AfterImportOptions.
Glenn Maynard