Bug 5975: Rapid number entry on SCT can cause model crash [1]
Bug Number: 5975
Release notes (y/n): Yes
For Release Nums: 7.1

This crash was difficult to diagnose.  It turned out to be a race condition 
involving KEY PRESS EVENTS in the QTableView subclass (SctTableView) and the 
life cycle of the INCELL EDITOR managed by the QAbstractItemDelegate subclass 
(SctTableDelegate).

In the SctTableView::keyPressEvent (QKeyEvent*) method, a query to the 
SctTableDelegate to determine whether or not an incell edit is in progress 
IS SOMETIMES MISTAKEN around the time the editor is being deleted.  That 
query is based on the incell editor widget being instantiated.  I modified 
the processing of that method to do a SECOND check by calling the base class 
keyPressEvent method (which results in the event being processed by the 
delegate class), and noticing whether or not the QKeyEvent instance comes 
back in the "accepted" (consumed) state.  In that case, we regard the edit 
as still, effectively, being in progress, so avoid processing of the event 
in the SctTableView::keyPressEvent() method.

That method is a bit complicated.  It needs to support "I" and "O" keys as 
special operations -- setting a flag and moving to the next timestep.  And 
it needs to avoid those characters initiating an incell edit.  There is also 
a workaround in there to avoid what seems to be a very strange feature of 
jumping to a particular cell based on entry of a digit if no cell is selected.

SctTableView (a QTableView) now uses a new QHeaderView subclass
(SctHeaderView), to make possible the monitoring of virtual method calls.
Currently, only the following virtual method is defined, and does still 
apply a "sanity check" on its two QModelIndex parameters.  That sanity check 
had detected the 5975 condition before the crash in DEBUG builds, but not in 
RELEASE builds.  With the higher-level fix in place (described above), we 
don't ever expect the sanity check to fail.