The II operator takes a range and returns a single cell that is in the same column or the same row
as the present cell.
This is needed for backwards compatibility with old Excel models and as a first step towards dynamic arrays.
In the past Excel would evaluate `=A1:A10` in cell `C3` as `A3`, but today in results in an array containing all
values in the range. To be compatible with old workbooks Excel inserts the II operator
on those cases.
So this PR performs an static analysis on all formulas inserting on import automatically the II operator
where necessary. This we call the _automatic implicit operator_. When exporting to Excel the operator is striped away.
You can also manually use the II. For instance `=SUM(@A1:A10)` in cell `C3`.
This was not possible before and such a formula would break backwards compatibility with Excel. To Excel that "non automatic"
form of the II is exported as `_xlfn.SINGLE()`.
Th static analysis has to be done for all arithmetic operations and all functions.
This is a bit of a daunting task and it is not done fully in this PR. We also need to implement arrays and dynamic arrays.
My believe is that once the core operations have been implemented we can go formula by formula writing proper tests and documentation.
After this PR formulas like `=A1:A10` for instance will return `#N/IMPL!` instead of performing the implicit intersection
This also fix old issues:
* Top border is only the top border of the selected area
(and not he top border of each cell in the area)
* Same for bottom, left and right borders
Factored out all the border related issues to a new file
This splits the webapp in:
* IronCalc (the widget to be published on npmjs)
* The frontend for our "service"
* Adds "dummy code" for the backend using sqlite
Updated the logic for handling months and days to improve date calculations. Also modified the constants for Excel date ranges to align with supported dates.
The way these functions interpret their arguments is inconsistent with
Excel in a few ways:
- EmptyCell: Excel ignores arguments evaluating to these types of
values, treating them as if they didn't exist.
- Text: Text cells are ignored unless they are "TRUE" or "FALSE" (case
insensitive). EXCEPT if the string value comes from a reference, in
which case it is always ignored regardless of its value.
- Error if no args: Excel returns a #VALUE! error for these functions if
no arguments are provided, or if all arguments are ignored (see
above).
- EmptyArg: Bizarrely, Unlike EmptyCell, EmptyArg is not ignored and is
treated as if it were FALSE by Excel.
- ErrorPropagation: Excel propagates errors in the arguments and in
cells belonging to any Range arguments.
Additionally, these functions are not consistent with each other, XOR,
OR, AND vary in how they handle the cases mentioned above.
Rectify these consistency issues by re-implementing them all in terms of
a single base function which is more consistent with Excel behavior.
The context was optional because I thought that paring an RC formula
did not need context.
You at least need the sheet in which you are parsing
For instance toknow if a defined name is local
