The breakage was due to the drawing layer re-work. We do need to store
charts (or all OLE shapes with associated listening ranges) for later
registration regardless of anchor types.
This eliminates the need to store the assigned doc pointer to cross-check
against whenever the edit engine is initialized. It's cleaner this way
& fdo#43614 still remains fixed.
There should only be one active edit view while the user is typing
into a cell, or else it crashes when an external input method is
being used to input values (such as Japanese).
also,
* make the GetEditView explicitly create EditEngine/EditView *always*
* remove the bogus GetLine method
* reset NotifyHdl when stopping the edit engine
In case the data source has a formula cell, the number format may be
inferred from the formula result in case the cell format is General.
Also,
1) no need to use UNO API in the API implementation. Let use the
internal API here.
2) this method didn't take into account the hidden cells.
TODO: We need to handle number formats for external ref data properly.
Setting a page-anchored object to cell-anchored didn't show the anchor
immediately until you unselect the object and re-select it. Same for
the cell-anchored to page-anchored direction.
This commit fixes it.
The old way was that an error cell was evaulated as having a value of 0.
The error cell also showed up as blank in the popup. Using the error
string is much more intuitive (and some users apparently want this
behavior).
We were supported to convert XML chart data range representations
with a hard-coded ';' as the range union operators, but incorrectly
using UI configurable range separators. This caused charts with
series that consisted of multiple ranges to be imported correctly in
locales where the range separator (which re-uses the function argument
separator) was something other than ';'.
BTW I plan to remove this "always use Calc A1 syntax" restriction in
future versions.
During Paint() in ScMultiTextWnd::InitEditEngine(),
ScTabViewShell::GetActiveViewShell() may return a view shell that does not
correspond with the document to be repainted if another document was opened or
when switching between documents. Prevent creating an EditEngine with wrong
SfxItemPool.
Otherwise we would fail to import the cell contents of those documents
that don't include table styles at all. Some hand-crafted ods documents
don't provide table styles, which 3.4 imported just fine.
Older releases stored a few function names not defined by ODFF, namely
EASTERSUNDAY instead of ORG.OPENOFFICE.EASTERSUNDAY, TDIST instead of
LEGACY.TDIST and B instead of BINOM.DIST.RANGE.
Since OOo/LibO 3.3 the proper function names can be read, additionally to the
"wrong" names. Now it's time to write the proper names and still accept the
incorrect ones.
Test cases are attached to AOOo issues:
ORG.OPENOFFICE.EASTERSUNDAY
https://issues.apache.org/ooo/show_bug.cgi?id=112882
LEGACY.TDIST and BINOM.DIST.RANGE
https://issues.apache.org/ooo/show_bug.cgi?id=110229
Note that the FALSE in A2 and A3 is a result of the string comparison of the
actual formula, that differs in separators (, vs ;) only.
(cherry picked from commit a9b03bd199)
This is also another unfortunate bug due to the logic change caused
by the DECLARE_LIST removal. There was one crasher due to out-of-bound
array access, plus one incorrect behavior concerning cell content
placement. Both are now fixed.
Some places in the code assumed that if the stack is empty a null pointer is
returned by top() (or old Pop()), this doesn't work anymore with ::std::stack
that instead has undefined behavior in that case, so check !stack.empty()
first before accessing top.
(cherry picked from commit ac40f7d650)
gsoc input bar now (should) snuggly wrap the text when collapsed, if multilines exist then scrolling with the keys should be clean and no spill from upper or lower lines visible. Removed some strange ( pseudo padding ) apparently for taking into account the window border and reorganized the resize logic so the padding is added ( and commented why ) in just one place.
For cell-anchored drawing objects. Failing to do so would result in
either one of
1) write error during file save,
2) drawing object disappearing upon reload, or
3) drawing object relocated to a wrong sheet, with wrong position
and size upon reload.
