GNOME Bugzilla – Bug 670558
Decimal cell value with deleted decimal places not updated
Last modified: 2012-02-22 00:53:21 UTC
Hi, To reproduce the bug: * open a new gnumeric sheet * type a number e.g. 215.31 into A1 * reduce the visible number of significant digits in A1 so that 215 now appears in A1. I used the toolbar button for this. * Modify the value to 215 in A1 by selecting the cell (double-click) or by using the formula text area i.e. delete ".31". * Confirm the deletion by pressing Enter. * value in A1 remains as 215.31 (double-click cell or in formula text area). To modify the number requires adding the requisite number of significant digits back (using the toolbar button, for example), then deleting the digits as described above. This is somewhat related to another bug I recently submitted: https://bugzilla.gnome.org/show_bug.cgi?id=670550 Thanks. Vince
*** Bug 670554 has been marked as a duplicate of this bug. ***
*** Bug 670556 has been marked as a duplicate of this bug. ***
Some further observations: Deleting the .31 from the input does not add an undo item, so when completing the edit, our system believes that the entered value is equal to the given value. On the other hand when you start editing the cell but do not change the content and hit "enter" you get a "Typing 215.31 in A1" undo item which should not appear. Clearly when editing finishes and we compare the new value with the old, we incorrectly compare with the displayed "215". So this is surely closely related with bug #555519. (I am keeping this bug separate from bug #555519 since there may be a slight difference.)
We have Breakpoint 2, cmd_set_text_full_check_text (iter=0xbfffe010, text=0x81e1df0 "215") at commands.c:755 ... (gdb) n 761 old_text = gnm_cell_get_entered_text (iter->cell); (gdb) 762 same = strcmp (old_text, text) == 0; (gdb) p old_text $7 = 0x86b0eb8 "215" In this situation old_text should have been "215.31". So gnm_cell_get_entered_text apparently returns the formatted text rather than the entered text.
Hmm, we have: 2009-01-12 Morten Welinder <terra@gnome.org> * src/cell.c (gnm_cell_get_entered_text): Apply cell format as well as value format. Applying only value format is certainly wrong. applying any format when we want to compare with the entered text is clearly wrong. I note that when we start editing and the 215.31 appears in the formula cell, we are _not_ triggering gnm_cell_get_entered_text. So at a minimum gnm_cell_get_entered_text is misnamed.
Even the concept of gnm_cell_get_entered_text is problematic. I think writing down the properties of the result might be a good start. I don't think all the callers expect the same set of properties.
With respect to the problem at hand, ie. the call to gnm_cell_get_entered_text in cmd_set_text_full_check_text, we really should compare the newly entered text with the text that we show in the cell when we start editing. Apparently we are not using gnm_cell_get_entered_text at that time.
Well in wbc-gtk-edit.c lines 985ff we have very specific formatting to obtain the string to be edited. (In general we do not want the truely edited string since the locale may have changed in the meantime and the display format may be lossy.) For this situation we should create a gnm_cell_get_text_for_editing that we can call whenever we need the string for editing.
Created attachment 208165 [details] [review] proposed patch This patch fixes the problem at hand by extracting the code from wbcg_edit_start that set the current content and moves it into gnm_cell_get_text_for_editing. The latter is then used in cmd_set_text_full_check_text.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.