Simple example. Type in a cell
and see Calc eat the first apostrophe (') in the formula input bar. However, typing in
retains the apostrophe in the formula input bar while not displaying it in the cell, which is a correct behavior.
Here, this apostrophe prefix is used to force cell content to be parsed as text, e.g. to force a number to be interpreted as text. But we need to retain it in case the content is real text.
A good place to start would be
That method is overloaded with several variants. Pick the one that takes String as one of the arguments, and work your way down. Somewhere, somehow we may be eating the apostrophe...
BTW Katarina, we've made a deal with Caolan that, in exchange for him fixing our favorite Writer bugs, we fix his favorite Calc bugs in earnest. And this is one of those bugs... :-)
So, bumping up the priority for this would be well appreciated. ;-)
> BTW Katarina, we've made a deal with Caolan that, in exchange for him fixing
> our favorite Writer bugs, we fix his favorite Calc bugs in earnest. And this
> is one of those bugs... :-)
> So, bumping up the priority for this would be well appreciated. ;-)
Fair enough, bumping prio then
So far, string cells beginning with ' were treated as follows: ScColumn::SetString (column3.cxx) stored n-1 chars (everything but ' char) into ScStringCell object. Later, ScTabViewShell::UpdateInputHandler (tabvwsha.cxx) when re-constructing the string to show in the edit field, appended ' char again, but only(!) if the string was actually a number. The info that this cell needs a special treatment when it comes to trailing apostrophe was not stored anywhere and that's why it didn't work for strings such as "'foo".
So what I've done is that I introduced a bool flag to ScStringCell to somehow remember that this cell is "special" (ie. its content is indeed a string and this is enforced by ' char at zero position). Otherwise, I kept the logic (striping and prepending ' char, as needed).
Attaching patch in a while
Created attachment 44130 [details]
This should fix the bug. Tested it a bit and it works for common cases. Please review, comment, complain etc.
So, the history behind it is that, when you type '10 into a cell, the cell should interpret it as text, even though it's a number.
These days, we do the same by setting the cell format to Text, but we still do this for backward compatibility (I guess), and/or because Excel still does it.
Regarding the patch, I'm not too keen on adding a special flag with the cell instance itself. Let me look around and see if we can do it another way...
I fixed this. There was a simpler way to handle this.
BTW the unit test also detected an abuse of this behavior in the datapilot output creation code, which I removed with great pleasure. :-)