Scenarios: Unit and Unit Scheme related fixes 
Bug Number: none
Release notes (y/n): no
For Release Nums: 6.3

  o Four (4) Unit Related Fixes
  o Two (2) Non-Unit Related Fixes

==================
UNIT-RELATED FIXES
==================

(1) Scenario Change callbacks (from SimWS) needed to be added 
to the Scenario Playbox Configuration Dialog (ScenPlayboxConfigDlg).

(2) The Offset Limit stored in ScenarioInputConfig "InputConfig" records is 
a numeric value WITH a ScaledUnit.  That needed to be converted to the units 
of the Scenario Input Slot's model slot each time units changed.  A check for 
a need for this is done now each time an "InputConfig" record is retrieved -- 
which now occurs in response to UnitScheme changes handled by the new callback 
processing of the prior item (and in other relevant places in their normal 
course of operation).  See new method:

   // returns indication that a change was made to the offset value/units.
   bool ScenarioPlayboxConfig::InputConfig::updateOffsetUnitsFromSlot();

(3) The computation of a series slots extrema -- for the purpose of initializing
the Scenario Manager's default values when newly editing Input Slot Min and 
Max values -- and for the that dialog's special "Compute Min/Max Values from
Baseline Slots" operation -- NEED TO BE performed in USER UNITS when irregular
per-time factor units (e.g. acre-ft/month) were used.  The following screenshots
illustate the problem when applied to a flow slot with an (actual) constant 
value, but when displayed in acre-ft/month:

  OK: http://cadswes2.colorado.edu/~philw/2013/Rw63-Prep/BugSceenshots/MinMaxPerDay.png 
  BAD: http://cadswes2.colorado.edu/~philw/2013/Rw63-Prep/BugSceenshots/MinMaxPerMonth.png
  ... notice that the MIN value is the same as the MAX value, but data from which it was
  ... computed actually falls below that value.
  
See the use of the new optional bool parameter in these SeriesSlot methods:

    bool getMinMaxValues (double& min, double& max, 
                          bool computeInUsrUnits=false) const;
                         
    bool getMinMaxTimesteps (double& min, Date_Time& minDT,
                             double& max, Date_Time& maxDT,
                             bool computeInUsrUnits=false) const;

(4) The clipping feature in the transformation of baseline series slot values
to compute adjusted (scaled or offset) scenario input series slots needed to 
handle irregular per-time factor units (e.g. acre-ft/month) in display units
rather than standard units.  Not doing so resulted in the following:

   http://cadswes2.colorado.edu/~philw/2013/Rw63-Prep/BugSceenshots/AcreFeetClipBug.png
   ... the current adjustment is so extreme that ALL VALUES were being clipped
   at the maximum limit ... but notice the "jagged" green line at the MAX limit 
   indicating that different timesteps where being clipped at different values 
   (in the wonderland of acre-ft/month).

This was addressed by a significant computational enhancement to this method (which
was refactored to avoid duplication in AggSeriesSlot and SeriesSlot support):

   // Scaling Utility 
  void ScenarioSlotData::scaleLocalSeriesSlotFromBaseline (
                               int& valCnt, // returned
                               int& errCnt, // returned
                               SeriesSlot* localSlot,
                               const SeriesSlot* baseSlot,
                               double factor, double offset,
                               const ScaledUnitPtr offsetSuPtr,
                               bool minMaxClip);                           
                             
======================
NON-UNIT RELATED FIXES
======================

(5) In the Scenario Playbox (in SlotScaleSliderPanel.cpp), when 
formatting an Input Slot's adjustment slider position value, SIX
fractional decimal positions were always shown, even with huge values,
like ("120000.000000").  This is a crazy implication of specifying 
the "format" optional parameter, but not the "precision" optional 
parameter.
   BAD:   QString::number (val, 'f'); // default precision
   GOOD:  QString::number (val); // default precision
   
(6) When 'clearing', the Scenario Manager needed to drop its Playbox
configuration record.  Not doing so resulted in a ScaledUnitPtr crash 
on a subsequent model load (but not always -- I'm not sure of the 
exact condition).  See ScenarioMgr::clear();

---