Confirming a cell's content, to be different to existing cells with the same content in the same column, will see Calc prefer the existing cell's format for capitalisation, overriding the user's input.. but not for certain words. Perhaps those exceptions are those words in the dictionary. This behaviour also seems to stop after any successful change and reverse of that change. So, make two cells as "test" or "apple" and those are fine. Make two cells random new word e.g. "dfgdfgdgdfgdfg" and try to capitalise one character in that string that is not the last letter. The cells return to be both exactly the same capitalisation "dfgdfgdgdfgdfg". If you capitalise the last letter in one, then that works and any future corrections are retained too. Perhaps that non dictionary word is added to a helpful anticipation of typing list that unhelpful forces the capitalisation.
Please, describe step by step how to reproduce the problem. Set status to NEEDINFO. Please set it back to UNCONFIRMED once you have provided requested informations. Thank you for your understanding. Best regards. JBF
1. Make two cells in the same column equal to a random new word e.g. "dfgdfgdgdfgdfg" - a word not in the dictionary. 2. Try to capitalise any one character in that string, that is not the last letter. Confirm the change. Result I see: The cells return to be both exactly the same capitalisation, instead of acknowledging the change the user was trying to make to one of them.
Not reproducible for me. Please, which version are you using ? Best regards. JBF
Version: 4.2.7.2 Build ID: 420m0(Build:2)
and Linux Mint 17, if that makes a difference.
I can not confirm with LO 4.3.3, linux. I can confirm with Version: 4.5.0.0.alpha0+ Build ID: a26222f5af55e8ffe9784dd411485d3c5c72e983 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-12-07_01:55:26 Setting as new.
As I started trying to bibisect this bug, the bug appeared in all versions that I checked, the oldest commit being "oldest" in the "bibisect-43all"-repository, i.e. commit 65fd30f5cb4cdd37995a33420ed8273c0a29bf00, source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932. However, this was only the case for content newly inserted into cells, i.e.: * The bug occurs when I do the following: 1) create a new calc sheet 2) insert "abcdefgh" into cell A1 3) copy the content of A1 to A2 4) replace the lower-case "e" in A2 by an upper-case "E" 5) confirm (by pressing "Return" or clicking into another cell) * The bug does not occur when I do the following: 1) open an existing file that has "abcdefgh" in A1 and A2 2) do steps 4 and 5 from above Therefore this does not seem to be a regression between the mentioned versions (except the bug had been fixed reintroduced after having been fixed). In this case, the "bibisectRequest" keyword should possibly be removed. (In reply to raal from comment #6) > I can not confirm with LO 4.3.3, linux. > > I can confirm with Version: 4.5.0.0.alpha0+ > Build ID: a26222f5af55e8ffe9784dd411485d3c5c72e983 > TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: > 2014-12-07_01:55:26 For me, the behaviour as described above was the same when using 4.3.3.2 on Debian.
I am removing "bibisectRequest" from whiteboard due to explanation in comment 7.
Not reproducible for me in LO master (Version: 5.2.0.0.alpha0+ Build ID: 1be6c440c645e441af0e04ba7711e4b2d80aad63) built at home under Ubuntu 15.10 x86-64. Closing as WorksForMe. Please feel free to reopen if you disagree. Best regards. JBF