right subcell as first responder!
This fixes the following bug: when selecting a cell whose content is too
long to be displayed, the scrolling is broken
There was a lot of code duplication.
I removed the initialization of xLabel{} and yLabels{} because those are
scratch buffers that shouldn't be accessed before being written to
anyway.
scroll "smartly" when scrolling to a too-big-to-be-displayed rect
This fixes calculation history navigation on big cells (that are bigger
than the displayed table)
This fixes crashes: indeed, in the way it was done before, we called
scrollToSubviewOfTypeOfCellAtLocation after setting the new selected subtype
and before reloading the data. However, selecting a new subtype might expand
the selected cell which can temper with the cell repartition. If so, we need to
reload the data to be able to call 'selectedCell' for instance.
table. Otherwise, the Poincare pool store useless layouts for cells that
aren't displayed.
This fixes the following issue: input "(transpose([1 2 3 4 5 6][1 2 3 4 5
6])^8", the computation works, clear the history, input the same
calculation again, it fails with a memory error.
At the moment ViewController::viewWillAppear doesn't do anything, so
there is no real impact. But if we want to use it it needs to be called
from subclasses.
When each Calculation had its own text buffer, the Expression of an
overflowing output text was Undefined. Hence that Expression could have
been Undefined without the corresponding text being 'undef'. That situation
may not happen anymore since Calculation are stored in a shared buffer.
The most common case where only the approximate output is displayed
happens when the exact and the approximate outputs are equal, more
precisely when the exact output is equal to the approximate output with
the number of significant digits taken from user settings. That
clarification matters for the Poincare::Integers which have more digits than
the number of significant digits set by the user.
Besides, an Expression containing Units is simplified as
Multiplication(Float, Unit...) recorded identically into the exact and
the approximate outputs (except perhaps the number of significant
digits). Generally, the case where the number of digits in the output is
smaller or equal to the user setting would be matched by the condition,
stated above, that exact and approximate output are equal. But that
should also be the case whatever the number of significant digits. That
is why the presence of Units is matched specifically.
