After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 670558 - Decimal cell value with deleted decimal places not updated
Decimal cell value with deleted decimal places not updated
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
1.10.x
Other Linux
: Normal major
: ---
Assigned To: Jody Goldberg
Jody Goldberg
: 670554 670556 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-02-21 16:22 UTC by Vince
Modified: 2012-02-22 00:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (9.97 KB, patch)
2012-02-21 20:40 UTC, Andreas J. Guelzow
committed Details | Review

Description Vince 2012-02-21 16:22:13 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
Comment 1 Vince 2012-02-21 16:28:16 UTC
*** Bug 670554 has been marked as a duplicate of this bug. ***
Comment 2 Vince 2012-02-21 16:28:38 UTC
*** Bug 670556 has been marked as a duplicate of this bug. ***
Comment 3 Andreas J. Guelzow 2012-02-21 17:28:56 UTC
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.)
Comment 4 Andreas J. Guelzow 2012-02-21 17:53:58 UTC
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.
Comment 5 Andreas J. Guelzow 2012-02-21 18:03:08 UTC
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.
Comment 6 Morten Welinder 2012-02-21 18:41:15 UTC
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.
Comment 7 Andreas J. Guelzow 2012-02-21 19:09:09 UTC
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.
Comment 8 Andreas J. Guelzow 2012-02-21 19:20:39 UTC
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.
Comment 9 Andreas J. Guelzow 2012-02-21 20:40:44 UTC
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.
Comment 10 Andreas J. Guelzow 2012-02-22 00:53:21 UTC
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.