When you switch to a different scheme, or modify or add an exception:

SERIES TAB:

• GOOD: Column header units text changes (if shown).
• GOOD: Row header units text changes (if shown).
• GOOD: Data cell numeric values change.
• GOOD: Selection statistics (at the bottom of the screen) are recomputed with the new units.
• PROBLEM: The numeric entry field (QLineEdit) is not updated.

SCALAR TAB:

• GOOD: Values and Units update
• MINOR PROBLEM: Similar to above, but instead of just not being updated, the numeric entry fields just clears. (So, is not, in fact, as much of a problem. This is a relatively rare circumstance, and no incorrect data is shown).

OBJECT GRID:

• PROBLEM: NEITHER values nor scale are updated with a unit scheme "switch" or change.
  However unit changes DO show up when either:
  1. Switching to a different SCT tab, and then back again, or
  2. Toggling the "Show Units" checkbox off and on.

(1) Addressed above. YES for Series and Scalar Tabs. NO for the Object Grid Tab.
(2) NO. This question refers to the idea that we would show the Unit Scheme Name somewhere in the SCT if units were not shown. (Units are shown either in the row or column headers, depending on the axis orientation. They can be shown or hidden independently for the two axis).

NOTE: Operating the SCT Config Dialog with the Object Grid Tab is in use (i.e. at least one cell defined) results in a CRASH:

• Gnats 5287: CRASH: SCT Gridded Object Tab: applying SCT Config when a Cell Object is defined.
• UPDATE [3-21-2013]: I see the problem, and this will be easy to fix. Technical: The GriddedObjTableConfig class needs an explicitly coded assignment operator which creates new copies of the Cell items in its Cell collection. The required change is limited to this one module.

YES. With respect to Unit Schemes, only the Adjust Values operation is particularly relevant. This brings up a modal dialog box which includes an option in which a numeric value is specified in the currently active units for the slot. The units for the slot from the Unit Scheme are correctly presented, and the result of the Adjust Values operation on the set of selected cells is numerically correct.

Note-1: Suggested Change: In the Adjust Values dialog, the user can't just enter a number and HIT THE ENTER KEY to apply the offset. The "OK" button is not the default button (nor is the "Cancel" button). Generally we don't want default buttons active in dialogs with muliple entry widgets. But in this case, the "OK" button should be an active default button so that when the user hits the Enter key, the offset is applied.

Note-2: There is an enhancement (since RW 6.2) to the Interplotion function -- in both the SCT and the Open Slot Dialog -- which should perhaps be featured in "What's New" notes. The Interpolate function now supports an operation to interpolate BETWEEN (and not overwrite) intervening Inputs (if any are found). See this image. One possible application of this is filling in GAPS within series data. For that particular purpose, it might be good for the text message accompanying that option to indicate how many intervening timesteps DON'T have an Input flag, rather than only how many timesteps do.

• BTW, See my recent e-mail [3-8-2013: "Re: URGWOM task 7 -- Missing Input Values"]. This algorithm (idea) might be considered as a DMI option to address the requirement of that task -- if I'm correctly understanding the nature of that issue.

Yes. There is a distinction between ordinary (application-internal) copy and paste of values and Export/Import Copy and Paste. Both types work as expected -- and differently from each other -- with the various types of Unit Scheme change operations.

With ordinary copy and paste, when slot values are copied, and unit scheme changes are made, the ultimate paste operation is performed in such a way that the actual physical quantities are preserved, and are presented in the target's current units according to Unit Schemes. This was tested in "both" directions to and from regular and irregular per-time units (e.g. cfs and acre-feet/month).

See the next section regarding the Export/Import Copy and Paste operation.

A general observation I have about Copy / Paste in the SCT is that the "paste / paste as inputs" distinction nuance was a mistaken notion, and should be greatly simplified. If the user is doing a paste operation in the first place, they should just go in AS INPUTS, regardless of whether or not the original values were copied from input-flagged cells.