Re: [lmi] visual feedback when editing cells

[Greg Chicares]

On 2011-08-09 16:29Z, Václav Slavík wrote:
> 
> when I press Ctrl+E in census view, there's a noticeable delay until the
> dialog appears. This can be frustrating, I am unsure whether I pressed
> the right shortcut or not and sometimes press it twice.
> 
> The small patch below adds visual busy indicator. IMHO it makes the
> situation much better -- at least you know something is happening and
> the app isn't ignoring you.

I agree with this idea, and am about to commit a rather similar change
that differs in a couple of ways.

First of all, if a busy cursor is wanted for Ctrl+E in a "census" context,
then it's wanted in an "illustration" context as well, so I factored out
the editing function shared among "census", "illustration", and "MEC"
input. Then I applied your patch in the new generic function, and found
that, in reasonable circumstances that arose in my testing, the lengthy
operation was interrupted by a messagebox--but the cursor remained "busy"
when placed anywhere in the lmi window except for the messagebox. I feel
that's kind of scary: a busy cursor that persists indefinitely while
awaiting user input suggests that the program is hung, IMO. I identified
the function that pops up that messagebox; it occurs at the beginning of
MvcController::MvcController() and takes little time itself; I satisfied
myself that the rest of that ctor shouldn't trigger any messagebox unless
something's gravely wrong, so that's where I'm going to show the busy
cursor. I measured this: the total Ctrl+E delay is 500 ms on my machine,
and the change I'm about to commit covers 300-400 ms of that.

Along the way, I decided we should address some defects in the Ctrl+E
handler--one that was marked (20110814T2332Z) and another that wasn't
(20110814T1340Z) but could cause a mystifying problem with drill-down
editing. A desirable side effect is that the "illustration" Ctrl+E
handler now doesn't recalculate anything if input doesn't change; the
same is true of the "MEC" Ctrl+E handler, which also (harmlessly) gets
a busy cursor even though it's not terribly slow.