computed when the calculation is added to the store and don't change afterwards.
Otherwise, if their heights change when scrolling (due to a modification of the
display output type - ExactOnly, ApproximateOnly...), it generates crashes.
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
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.
only when the calculation is actually expanded (when the output is
selected and the display output is ExactApproximateToggle)
This avoid blinking when changing input/output selection
three expressions but no more BurgerMenuView.
ScrollableExactApproximateExpressionsView and
ScrollableInputExactApproximateExpressionsView inherit from it.
When scrolling up and down, only 'setCalculation' is called by
'willDisplayCellForIndex' - and not 'cellDidSelectSubview'. So a new cell
should be informed of the expanded state in 'setCalculation'.
should decide which subviews is displayed.
'setCalculation' is the only method called when scrolling (when using
a new cell for a calculation) so it should take into accound whether the
cell is expanded or not.
This fixes the bug: when pushing several calculations (which expand) in
the store, scrolling up and down corrupts the cells contents
ScrollableExactApproximateExpressionsView into
AbstractScrollableExactApproximateExpressionsView and
ScrollableExactApproximateExpressionsView to factorize code with future
ScrollableInputExactApproximateExpressionsView
to a cell selection, the cell used for the selected row might change. We
thereby have to update the selected cell once the table has been
reloaded.
This fixes the following bug: add 5 times the calculation "12.2". Go up,
the selected expression is the left one instead of the right one.
It is not very probable that a new CRC32 should be computed to 0, and
maybe not less probable than being computed to the CRC32 of an empty
computation. However this was not mathematially verified.
