Fixed a bug involving mishandled negative offsets in
CalculationSelectableTableView::scrollToSubviewOfTypeOfCellAtLocation
and cleaned up the function.
Change-Id: I4394ca9dc9748e8b761e7f722e41014d71d3373f
responder, scroll to the bottom of the table (and not the last cell).
Indeed, the last cell might be to big to be displayed and scroll to it
might scroll to its top.
This fixes the following bug: input 1/2/3/4/5/6/7/8, OK, up, down. We
did not scroll to the bottom of the table.
When displaying a calculation taller than the screen, the output could
be displayed above the screen.
- type 1/2/3/4/5/6/7/8/9 (the main fraction between the 1 and 2)
- press UP to select the output
==> The output is still offscreen.
Change-Id: Ic3ed7664ae693d22486f8b2f9f3a8f2324c3d7c9
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.
In SelectableTableView::selectCellAtLocation, we call 'tableViewDidChangeSelection'
before scrolling. Therefore, the cell with updated with the right selected subview
is not the one drawn... To solve this issue, we keep the selectedSubview ('model')
in the HistoryController instead of in the limited-lifespan view.
