Problem description: Setting number format for empty table cells does nothing. Steps to reproduce: 1. Create a table in a writer document. 2. Move the cursor into an arbitrary table cell. 3. In the table number format dialog set the number format to any non standard format. 4. Enter a number into the cell. 5. Set the cursor outside the cell to trigger the formatting. Current behavior: Nothing happens. Expected behavior: The previously selected number format is applied to the number. Opening the number format dialog for that cell again shows the format change has not been saved. Platform (if different from the browser): Linux 32 bit (upstream binaries)
(In reply to comment #0) > Steps to reproduce: > 1. Create a table in a writer document. > 2. Move the cursor into an arbitrary table cell. > 3. In the table number format dialog set the number format to any non > standard format. > 4. Enter a number into the cell. > 5. Set the cursor outside the cell to trigger the formatting. > Current behavior: Nothing happens. > Opening the number format dialog for that cell again shows the format change > has not been saved. Confirmed with: LO 3.6.3.1 Build ID: f8fce0b Windows 7 Professional SP1 64 bit
*** Bug 58956 has been marked as a duplicate of this bug. ***
Removing regression keyword for now as I couldnt find a version named anywhere in this bug or in the dupe claimed to have worked properly. Feel free to bring the keyword back, if you specify a version where this used to work as expected.
Hi Bjoern, At least it works in LibreOffice 3.3.0 - providing of course via Tools > Options > Writer > Table Number recognition is activated.. Will try to find first version where it is broken.
Last version where it is OK: 4.0.2.2 First version where it is broken: 4.0.3.1
I can reproduce the described behaviour at the start of the 43all bibisect repository (3.5.0) However, by the end it appears to have already been fixed. It also still works as expected in 4.3.4.1 release and 4.5 master. Setting RESOLVED FIXED
It's not resolved in 4.3.5.1 on Linux, 32 bits
new document insert table set number format of cell A1 to currency > caret is right side of the cell = OK insert number, e.g. 34,5 (Dutch locale) > number jumps to left = WRONG again set number format of cell A1 to currency > number jumps to right and is preceded by "€ "
why has this never been marked as MAB ?
OK, following comment 8 I get the following from bibisect-43all: b68886f4c56ebc4cdf94aee9753398ccce28bb41 is the first bad commit commit b68886f4c56ebc4cdf94aee9753398ccce28bb41 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed Nov 27 01:52:45 2013 +0000 source-hash-90830788b1f8fd61ea86135712868aeda395edd0 commit 90830788b1f8fd61ea86135712868aeda395edd0 Author: Noel Grandin <noel@peralex.com> AuthorDate: Mon Sep 16 14:31:09 2013 +0200 Commit: Noel Grandin <noel@peralex.com> CommitDate: Tue Sep 17 09:06:12 2013 +0200 convert the SvxAutoCorrect::FindIn* methods from String to OUString Change-Id: Ida2f39b75f73137a4164d95d7f1e9a6cd34a322f git bisect start 'latest' 'oldest' # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b git bisect bad 4850941efe43ae800be5c76e1102ab80ac2c085d # skip: [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681 git bisect skip a043626b542eb8314218d7439534dce2fc325304 # skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6 # skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6 # skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6 # bad: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930 git bisect bad c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31 # bad: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930 git bisect bad c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31 # good: [1d4980621741d3050a5fe61b247c157d769988f2] source-hash-89d01a7d8028ddb765e02c116d202a2435894217 git bisect good 1d4980621741d3050a5fe61b247c157d769988f2 # skip: [89110ca258fa7a15dfc546acfb39e76fc3eb2a44] source-hash-e450a2c506ac7cd4433b0f93fc750a89919bc03c git bisect skip 89110ca258fa7a15dfc546acfb39e76fc3eb2a44 # good: [1cca92a409385d9288c28a54d5e3008e56728bc0] source-hash-7be7824bbbdeee6fa998b950e6046ab37fe690cb git bisect good 1cca92a409385d9288c28a54d5e3008e56728bc0 # skip: [5fa28ce2931a35ae64ae08d3904cfb76d24459d8] source-hash-2304beaca33c63b94df99cb827716f00ce259f9a git bisect skip 5fa28ce2931a35ae64ae08d3904cfb76d24459d8 # bad: [2a9ff869c5638dc5c3aa387d0fe55c3291c86288] source-hash-01b7e04172889cbc9e4ac404b105e18ddc062d6f git bisect bad 2a9ff869c5638dc5c3aa387d0fe55c3291c86288 # bad: [9771d0c212cfa71b07742ff3dc5c05df22d600eb] source-hash-a9a0933ec67eab0ec31c8fadb60fb8e8e3e90485 git bisect bad 9771d0c212cfa71b07742ff3dc5c05df22d600eb # bad: [b68886f4c56ebc4cdf94aee9753398ccce28bb41] source-hash-90830788b1f8fd61ea86135712868aeda395edd0 git bisect bad b68886f4c56ebc4cdf94aee9753398ccce28bb41 # good: [56d7a7963ef4d32b0c5b60dc5f85d4bc218785d9] source-hash-1a412370ab03af8f3865ccbfaaa8dcff1d0ac0ad git bisect good 56d7a7963ef4d32b0c5b60dc5f85d4bc218785d9 # good: [1cb483c5f696c8e7d262c7959e482f2bc2edc0cb] source-hash-59373b753902f69cd44d183568b084429322e7ab git bisect good 1cb483c5f696c8e7d262c7959e482f2bc2edc0cb # good: [d3b6cc309837997ba693f21d82b5d8ce866db756] source-hash-cb4e009c4539c535108021934e545194b35cad9d git bisect good d3b6cc309837997ba693f21d82b5d8ce866db756 # first bad commit: [b68886f4c56ebc4cdf94aee9753398ccce28bb41] source-hash-90830788b1f8fd61ea86135712868aeda395edd0
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
still a problem in daily Version: 4.5.0.0.alpha0+ Build ID: 9efd80ac32a80656ed6482df69615227d12bc6d9 TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-03-30_16:43:31 Locale: nl_NL I saw an older issue tdf#32082 that is for the same problem, and a commit that should have fixed it: http://cgit.freedesktop.org/libreoffice/core/commit/?id=f8be3d02573c4d6d753b5e0c1a449e932f94bd81
@Cor Nouws: Do you by any chance have both "Number recognition" and "Number format recognition" enabled? I've identified an issue, just not sure if it's exactly the issue you're seeing. As I understand it, there are three cases which should work with number recognition, covering a table cell with a number format already applied, when: A) Both "Number recognition" and "Number format recognition" are off B) Only "Number recognition" is on C) Both "Number recognition" and "Number format recognition" are on (in each case, a formatted number should result from entry into the cell, with some variations on what input is acceptable and what the result is. There appear to be other problems with which number results and what kind, but that's not the issue here) Before the above-mentioned commit f8be3d02573c4d6d753b5e0c1a449e932f94bd81, it seems to me that, for at least UK and Dutch currency formats, when inputting numbers of the forms "12.34" and "12,34" respectively, A) FAILS, B) Works, C) Works whereas after, A) Works, B) Works, C) FAILS
(In reply to Matthew Francis from comment #13) > @Cor Nouws: Thanks for your hints Matthew. I marked this issue for consistent scenario testing..
Created attachment 117111 [details] test case for all possible scenarios.. Attached a test case... Some work to fiddle all out, and not surprisingly some things break now and then!
NB In 5.0.0.2, - setting number recognition and format date in an empty cell, does work. Nice. - setting number recognition and format number in an empty cell, does not work.. Shouldn't we ask on a list to find some brave testers for this?
Hi, I pushed a patch that touches this issue and hopefully fixing a few remaining issues. I've been testing this back and forth so much I'm unsure of what works and what doesn't. Could someone please help me test this.
(In reply to Cor Nouws from comment #16) > - setting number recognition and format number in an empty cell, does not > work.. This now seems to work in 5.1. If I enable Tools > Options > Writer > Table Number recognition and format a cell as Number, some non-standard, user-defined thing, it stays left-aligned (as in Expected). I hope I understood it correctly. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: db6a928a420868b2a80ba11c8d46151d16c13624 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-05_22:13:24 Locale: fi-FI (fi_FI)
(In reply to Beluga from comment #18) > This now seems to work in 5.1. > If I enable Tools > Options > Writer > Table Number recognition and format > a cell as Number, some non-standard, user-defined thing, it stays > left-aligned (as in Expected). > > I hope I understood it correctly. If you first did set the number recognition and then entered values in the cells: yes :)
Created attachment 120603 [details] result in 5.1 daily this definitely works in 5.1 daily 2015-11-09
Hi Niklas, (In reply to Niklas Johansson from comment #17) > Hi, I pushed a patch that touches this issue and hopefully fixing a few > remaining issues. I've been testing this back and forth so much I'm unsure > of what works and what doesn't. Could someone please help me test this. Thanks a lot! I think your commit http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa334d55ee34c125f6f4fdfaadbc1ed8fa33f5bc did a great job :) Would it be possible to push that to the 5.0 branch too? Still some releases to go there.
Created attachment 120604 [details] test results daily 20151109 @matthew (In reply to Matthew Francis from comment #13) > A) Both "Number recognition" and "Number format recognition" are off > B) Only "Number recognition" is on > C) Both "Number recognition" and "Number format recognition" are on > > Before the above-mentioned commit f8be3d02573c4d6d753b5e0c1a449e932f94bd81, > it seems to me that, for at least UK and Dutch currency formats, when > inputting numbers of the forms "12.34" and "12,34" respectively, > > A) FAILS, B) Works, C) Works > > whereas after, > > A) Works, B) Works, C) FAILS I think all works fine - see table in attached. Of course there are more corer cases that are not covered in that table, but I did additional test and confirm that if i.e. format is set, but not recognition, 12-1 will not result in a date in a cell with decimal number format, but will in a cell with date formatting.
Let's set to fixed for now.
(In reply to Cor Nouws from comment #21) > Would it be possible to push that to the 5.0 branch too? > Still some releases to go there. Sure, that was always my intent. I just wanted a few more eyes checking that everything seems ok. I cherry-picked the change and pushed it to gerrit for review. https://gerrit.libreoffice.org/20082
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
testing for tdf 48763 I verify this one ;) Version: 6.1.0.0.alpha0+ Build ID: a9b202a6b7000e7af34f2a639ca207122a3968bf CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-12-26_23:09:36 Locale: nl-NL (nl_NL.UTF-8); Calc: group threaded